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(57) Abstract 95 

In a computer graphics system, an address 
generator processes physical and virtual addresses 
using a common command set. A separate transla- 
tor provides conversion from generated virtual ad- 
dresses to physical addresses. The address generator 
formulates addresses as a function of distance from 
the origin of desired destination area in destination 
memory to the requested position in the destination 
area. A plurality of drawing graphics commands 
specify different raster drawing operations. A plu- 
rality of context graphics commands is used to de- 
fine a desired context in which drawing graphics 
commands operate. The defined context includes 
destination location for resulting data, type and 
plane depth of graphics operations, foreground 
and/or background color of resulting data. Differ- 
ent parts of the context are changeable/redefinable 
independently of the other parts. The graphics com- 
mands have a format of multiple fields. Different 
fields specify different parameters. For each gra- 
phics command, the fields are arranged in order of 
common use of the corresponding parameter such 

that fields of less commonly used parameters are at an omittable end of the format. Thus, length of each graphics command va- 
ries as a function of parameters specified in the graphics command. A desired set of raster drawing commands delimited by a be- 
ginning indicator and an end indicator form a drawing unit. For clip list processing, a drawing unit is stored as a single occur- 
rence in the system command buffer but functionally serves as a processing loop. Processing alternates between the drawing unit 
held in the command buffer and a clip list that specifies desired clip rectangles, the drawing unit being repeated for each clip rec- 
tangle. 
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TITLE: ADDRESS METHOD FOR COMPUTER GRAPHICS SYSTEM 
BACKGROUND OF THE INVENTION 

A typical computer graphics system employs a memory 
source of data to be displayed, an address generator, a 
5 graphics controller, and a video display unit (e.g., CRT and 
the like) . Graphics commands are transmitted from a host 
processor and- are written to a register interface. Operands 
of the graphics commands are stored on the graphics 
controller. Common variations of this include: 

10 f 1 ) the graphics controller reads graphics commands only 

from main memory via physical dma; 

(2) the graphics controller reads graphics commands from 
physical main memory and can move operands between graphics 
controller memory and main physical memory. However, graphics 
15 operations cannot occur until the data is in graphics 
controller memory. 



The stored operands include source addresses (i.e., main 
memory addresses) of data to be displayed and so-called 
destination addresses (i.e., memory locations in a frame 
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buffer that supports the video display) . Under the control 
of timing signals, the address generator provides appropriate 
pairs or sequences of operand addresses while the graphics 
controller sequentially operates on respective data to 
5 generate desired screen views on the video display unit. In 
particular, the graphics controller reads memory data into the 
frame buffer with respective source data being placed at 
respective destination addresses in the frame buffer. 
Thereafter, graphics controller provides display of data 
10 through the display unit by enabling sequential reading of the 
contents of the frame buffer. That is, the frame buffer 
supports raster scanning from a first line through succeeding 
lines of the screen view on the display unit such that the 
screen view is continuously refreshed. 

15 Existing problems or disadvantages of computer graphics 

systems of the prior art include: 



Lack of direct access of virtual memory and lack of 
write access to main memory; 



20 



The address generator can only draw to its own 
memory, i.e., the frame buffer or a graphics- 
private memory. This is a cost disadvantage, and 
in the case of large operands can be a perfomance 
di s advant age ; 



30 



25 



The application/program (client) requesting 
execution of a graphics command is required to 
provide physical addresses if the graphics 
controller has the capacity to access main physical 
memory. Furthermore, if a graphics operation spans 
virtual pages, the client program must segment and 
translate virtual memory boundaries for each 
graphics operation so they don't span physical 



35 



pages; 

High overhead for context setup, i.e., setup 
commands, to support a series of graphics 
operations and clip list processing commands. 
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The present invention provides a computer graphics system 
that addresses the problems of prior art. In particular , the 
present invention provides direct access of main memory by the 
5 graphics system (i.e., main memory access without host 
processor action) . With respect to the address generator, the 
frame buffer is separately accessible (i.e., non-dedicated) 
as are I/O devices and main memory. Further, the address 
generator processes virtual as well as physical memory 
10 addresses such that requesting applications /programs or the 
host processor are no longer required to translate virtual 
memory addresses. In addition, graphics commands are 
configured to minimize redundancy in setup of graphics 
operations and clip list processing. 

15 In accordance with one aspect of the present invention, 

a common command set is employed to process virtual memory 
addresses and physical -memory addresses alike. Addressing is 
then as follows. A destination memory has an initial memory 
position from which positions in the destination memory are 

20 -addressed. A desired destination area has an origin within 
the destination memory. For a given position in the 
destination area relative to the origin of the destination 
area, the present invention determines a working distance from 
the origin to the given position along one axis (e.g., along 

25 a scanline) . The present invention forms a destination memory 
address of the given position (relative to initial memory 
position of the destination memory) as a function of the 
determined working distance. In particular, the determined 
working distance is summed with a differential distance. The 

30 differential distance is defined as the distance between the 
origin of the destination area and the initial memory position 
of the destination memory, along the one axis. Further, the 
present invention forms source memory addresses and stencil 
memory addresses each as a function of the determined working 

35 distance . 
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In accordance with another aspect of the present 
invention, clip list processing employs a list-setting command 
and entities called "drawing units" which correspond to series 
of desired raster drawing commands . Each such series of 
5 desired drawing commands is delimited by a beginning indicator 
and an ending indicator. For each drawing unit, a memory list 
indicating desired destination areas (i.e., clip rectangles) 
is formed. That is, the memory list has a different entry for 
each desired destination area, and each entry provides the 

10 memory address for accessing the corresponding destination 
area. A list-setting command indicates memory address of the 
memory list and is stored in the system command buffer 
immediately preceding the corresponding drawing unit. The 
commands held in the command buffer are sequentially executed 

15 such that the list-setting command is executed before the 
series of drawing commands in the drawing unit . In response 
to the list-setting command, the present invention (i) 
accesses the memory list with the memory address indicated in 
the list-setting command, and (ii) sequentially reads the 

20 entries in the memory list, and for each entry executes the 
series of drawing commands as delimited in the drawing unit . 
To that end, the series of drawing commands is executed once 
for each desired destination area listed in the memory list, 
while being stored as a single occurrence in the command 

25 buffer. Thus, each drawing unit effectively serves as a 
processing loop in the command buffer. 

Further multiple drawing units may be executed against 
the same memory list. In a preferred embodiment, a control 
flag resets a pointer to the next drawing unit so that an 
30 additional list-setting command is not required. 

In accordance with a further aspect of the present 
invention, raster drawing commands are partitioned from set-up 
(or context) commands. The latter commands are used to define 
a context in which drawing commands operate to provide desired 
35 graphics operations on specified data. The context includes 
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destination location for resulting data, type of graphics 
operation, foreground color of resulting data and background 
color. Different set -up/context commands define different 
parts of the context independent of other parts of the 
5 context. To that end, context may be redefined by using a 
single set -up /context command to redefine one part of the 
context. The other parts of the context remain as previously 
defined. In the preferred embodiment, the context commands 
include commands for defining clip list processing and 
10 commands for defining type of graphics operations separately 
from clip list processing. 

In accordance with another aspect of the present 
invention, a command format enables length of the graphics 
system commands to vary. In particular, the command format 

15 includes a multiplicity of fields. Different fields are used 
for specifying different parameters of the graphics commands. 
The fields are arranged in order of common use such that less 
commonly used fields are at an omittable end of the -format. 
As a result, length of each command varies as a function of 

20 parameters specified in the command. 

To accomplish the foregoing, the command format includes 
a length field for indicating present length of the command. 
A flag field provides flags for inhibiting automatic updating 
(i.e., incrementing or decrementing) of pixel position on a 
25 given scanline in working memory, for inhibiting automatic 
updating (incrementing or decrementing) of a scanline in 
working memory, and for indicating direction of processing 
along an axis in a working memory. 

Thus, the objects and advantages of the present invention 

30 are: 

a computer graphics system that uses virtual main 
memory for offscreen operands. This eliminates the cost of 
maintaining graphics -private memory, eliminates overhead of 
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moving operands in and out of graphics controller memory and 
simplifies the programming model; 

a computer graphics system that implements various 
other functions in main memory which are typically implemented 
5 with graphics -private memory; 

a computer graphics system that provides an 
efficient programming interface and serves as an independent 
graphics co-processor that involves minimal to no CPU 
processing. 



10 BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, features, and advantages 
of the invention will be apparent from the following more 
particular description of preferred embodiments of the 
invention, as illustrated in the accompanying drawings in 

15 which like reference characters refer to the same parts 
throughout the different views. The drawings are not 
necessarily to scale, emphasis instead being placed upon 
illustrating the principles of the invention. 

Figure 1 is a block diagram of a computer graphics system 

20 according to the present invention. 

Figure 2 is a detailed schematic of a graphics control 
unit employed in the computer graphics system of Figure!. 

Figures 3A and 3B are schematic diagrams of address 
processing by an address generator employed in the graphics 
25 control unit of Figure 2. 

Figure 4 is a schematic illustration of clip list 
processing in the computer graphics system of Figure 1. 

Figures 5A through 5R are schematic illustrations of 
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graphics commands which form the command set employed in the 
computer graphics system of Figure 1. 

Figure 6 is a schematic illustration of source, stencil 
and destination operand spaces on which the graphics control 
5 unit of Figure 2 operates, 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

As used herein, the following terms have the following 
definitions : 

"Multi-plane" refers to a drawable surface which is 
10 deeper than one plane such that each pixel of the drawable 
surface is defined by two or more bits of data. For example, 
the term multi-plane may indicate an 8-bit-per-pixel colored 
window, pixmap, or image. 

"Monochrome" indicates a single plane (one bit per pixel) 
15 window, pixmap, or image. 

"Stencil" is a single plane image or bit map which is at 
least the size of the undipped portion of the destination. 

"Tile" is a term used generically to describe a source 
which, since it is smaller than the destination, must be 
20 "wrapped" one or more times in both X and Y in order to fill 
up the destination. 

"Stipple" is a special case of tile where the source is 
single plane and the destination is either single or multiple 
plane. 



25 



"Strip" is a subset of tile. Basically, a strip tiles 
in X but not in Y. The destination, therefore, must be of the 
same height as the source. 
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"Operand" refers to a working memory area to serve as a 
subject of a graphics operation. In particular, "operand" 
takes on the meaning of SOURCE, DESTINATION, and/or STENCIL 
to reference a source memory area, a destination memory area, 
5 and a stencil memory area as a second source, respectively. 

References to "Y" indicate a particular scanline in a 
desired memory area, and references to "X" refer to pixel 
position on a given scanline . 

"Octaword" is four 32-bit words. 

10 Figure 1 shows a block diagram of a computer graphics 

generation system 100 according to the present invention. 
Depending on configuration, computer graphics generation 
system 100 may be incorporated within a single-user 
workstation or a multi-user computer, or may be connected to 

15 a computer network by network bus 180 as shown. The computer 
graphics generation system 100 includes functional units such 
as a processor unit 102 (depicted within a broken-line block) 
interconnected via a CPU bus interface 24 8 to a system bus, 
generally designated 120, for communication with - a 

20 memory/graphics control unit 130. The system bus 120 is 
effectively shown as a plurality of buses, designated 112, 
113, and 114, each of which respectively, transfers data 
information (bus 112) , request information (bus 113) and 
address information (bus 114) . Memory data and memory address 

25 buses 122 and 124 connect in series the memory /graphics 
control unit 130, a main memory 140, and a video unit 150 
(shown in broken lines) . Video unit 150 in turn controls the 
display unit 116. The video unit 150 includes therein a frame 
buffer memory 151 for holding pixel data or pixmaps of the 

30 screen view displayed on display unit 160, and a digital-to- 
analog converter (DAC) 152. 

The memory/graphics control unit 130 is interconnected 
to a plurality of bus structures, each of which is 
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bidirectional for data/address transfers through, to and from 
the control unit 130. Such bus structures include the video 
unit 150 control bus structure, that is, video control bus 12 6 
and the cursor bus 128/ the I/O bus structure 170, formed of 
5 I/O data bus 132, I/O request bus 133 and I/O address bus 134; 
and a network bus structure 180, such as data bus 142, request 
bus 143 and address bus 144. Connected to the I/O bus 
structure 170 may be any type of peripheral device, such as 
disk storage unit 160 and any other suitable I/O device 162. 
10 Also connected to I/O buses 170 for enabling access to main 
memory 140 is a duplicate tag store 255. 

Further details of each of the foregoing elements and 
other elements in Figure 1 may be found in the cofiled Patent 
Application entitled "Computer Graphics System" by Kim 
15 Meinerth, et al, and assigned to the assignee of the present 
invention. That application is herein incorporated by 
reference, certain details of computer graphics system 100 
being repeated hereafter only as necessary for understanding 
the present invention. 

20 The components of computer grapnics generation system 

100, and in particular those components and buses surrounding 
graphics control unit 130, are arranged such that reading from 
memory, writing to memory and other operations are performed 
without any action by processor unit 102. More specifically, 

25 without action by processor unit 102: 

(i) graphics control unit 130 can access main memory 
140, frame buffer memory 151 directly, and can reference disk 
storage unit 160, and I/O devices 162 directly; 

(ii) graphics control unit 130 can transfer information 
30 between main memory 140 and frame buffer memory 151 within 

video unit 150; and 

(iii) graphics control unit 130 can transfer information 
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between both main memory 140 and frame buffer memory 151 and 
devices connected to network bus structure 180 or I/O bus 
structure 170. 

The foregoing is accomplished, in part, by the same memory 
data and address buses 122 and 124 being used by graphics 
control unit 130 to access main memory 14 0 and frame buffer 
memory 151. Said another way, memory address bus 124 supports 
graphics control unit 130 memory access with any address 
("physical" to main memory 14 0 or "virtual" to frame buffer 
memory 151) so that graphics control unit 130 can address any 
memory space either virtually or physically on memory address 
bus 124. As such, graphics control unit 130 utilizes a common 
command set for processing physical addresses (of main memory 
140) and virtual addresses (of frame buffer memory 151) alike. 
To that end, physical addresses and virtual addresses are 
treated similarly by graphics control unit 130 within computer 
graphics generation system 100. 

The method by which graphics control unit 130 
accomplishes the foregoing may be more easily seen by 
20 reference to Figure 2. Graphics control unit 130 consists of 
two functional parts, a memory control portion 220 and a 
graphics processor portion 210. The graphics processor 
portion 210 is formed of an address generator 196, pixel shift 
logic unit (pixel SLU) 172, virtual translation/FIFO control 
25 unit 200, mask generator 202, graphics data buffer 204, and 
video/cursor controller 20 6, all interconnected by two signal 
lines, the pixel data bus (PXDAT) 188, and flow control bus 
(FCTL) 208. The various graphics processor portion 210 
elements are also connected by a number of signal lines, which 
30 will be explained as they are relevant to the description of 
the operation of the graphics processor portion 210 . The 
memory control portion 220 consists of arbitration and flow 
control -unit 164, memory state unit 166, memory address and 
control unit 168, and memory data buffer 169, among other 
35 working multiplexes and interfaces . Pixel SLU 172 is a part 
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of both memory control portion 220 and graphics processor 
portion 210 for reasons that will be apparent later. 

Certain of the component units of memory control portion 
220 communicate various types of information over the various 
5 bus structures of Figure 1. Flow control unit 164 receives 
memory requests from respective incoming portions of the 
system request bus 113 (of Figure 1) , the I/O request bus 133 
(of Figure 1) , and the network request bus 143 (of Figure 1) . 
Flow control unit 164 (Figure 2) acknowledges memory requests 
10 through an external acknowledgement line which connects to 
respective outgoing portions of the system request bus 113 (of 
Figure 1), the I/O request bus 133 (of Figure 1), and the 
network request bus 143 (of Figure 1) . The memory address and 
control unit 168 receives the address portion of a memory 

15 request over a respective incoming portion of. the system 
address bus 114 (of Figure 1), the I/O address bus 134 (of 
Figure 1) , or the network address bus 144 (of Figure 1). 
Address/data output multiplexer 192 sends data on respective 
outgoing portions of the I/O data bus 132 (of Figure 1) and 

20 the network data bus 142 (of Figure 1) , and sends address 
information over respective outgoing address portions of the 
I/O address bus 134 (of Figure 1) and the network address bus 
144 (of Figure 1) . Data is received by pixel SLU 172 over 
respective incoming data portions of system data bus 112 (of 

25 Figure 1), I/O data bus 132 (of Figure 1), and network data 
bus 142 (of Figure 1) . Memory address and control unit 168 
sends address and control information over memory address bus 
124 to main memory 140 (of Figure 1) and frame buffer memory 
151 (of Figure 1) . Memory data buffer 169 sends data to and 

30 receives data from main memory 140 (of Figure 1) and frame 
buffer memory 151 (of Figure 1) over memory data bus 122, and 
also sends data to CPU bus interface 248 (of Figure 1) over 
the outgoing data portion of system bus 112 (of Figure 1) . 



Further descriptions of the interconnections and 
interaction between the components of graphics control unit 
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130 is provided next in an illustrative, non-limiting example 
of a memory request by disk storage unit 160. A memory 
request includes request information, which contains 
information about the requester, and address information, 
5 which contains the memory address of the requested data. The 
request and address information are processed separately. 

The request information for a memory read is transmitted 
from disk storage 160 over request portion 133 of I/O bus 
structure 170, to request input multiplexer 182 which 
transmits the request to flow control unit 164. Flow control 
unit 164 prioritizes the request and transmits request 
information over transmission line 174 to memory state unit 
166. Information transmitted includes information about the 
requester (in this example, disk storage unit 160) , access 
type, and operand size. Memory state unit 166 transmits the 
request information to memory address and control unit 168 
over request identification line 178. 

The address information of the memory location that is 
requested is transmitted over address portion 134 of I/O bus 
20 structure 1-70 and is multiplexed through address input 
multiplexer 184. Address input multiplexer 184 then transmits 
the memory address information directly to memory address and 
control unit 168 over "address in" (ADRSIN) line 186. 

Memory address and control unit 168 sends the request 
25 information received over line 178, according to the memory 
address information received over line 186, to main memory 140 
on memory address bus 124. Contents of the requested memory 
address are returned over memory data bus 122 to memory buffer 
169 and are then sent to pixel SLU 172 over memory data 
30 (MEMDAT) line 187. Pixel SLU, in turn, transmits the data 
over pixel data bus (PXDAT) to address and data output 
muliplexer 192. Multiplexer 192 transmits the data to the 
device that requested the memory read, namely disk storage 
unit 160, over I/O bus structure 170. 



10 
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A request for a memory read by processor unit 102 
proceeds in the same manner, except upon receipt of the 
contents of the requested memory address, memory data buffer 
169 transmits the data to processor unit 102 over CPU memory 
5 read data line 194 which relays to system data bus 112 of 
Figure 1 . Those familiar with the art will appreciate from 
this example that writes to main memory 140 by processor unit 
102 and I/O devices 160, 162 can be accomplished in a like 
manner, and that reads from or writes to main memory 140 by 
10 other devices attached to one of the bus structures of Figure 
1 is similarly accomplished. It can also be noted that the 
memory request by disk storage unit 160 and similar I/O 
devices 162 proceed without any action by processor unit 102. 

Requests for memory read or writes by graphics control 

15 unit 130 are as follows. Generally, such memory requests are 
in conjunction with graphics commands being executed by 
address generator 196 (discussed later) in graphics control 
unit 130. Address generator 196 issues memory requests over 
address generator request line 212, to virtual 

20 translation/FIFO control unit 200. Virtual translation/FIFO 
control unit 200 -in turn transmits the request to flow control 
unit 164, which transmits the request to memory address and 
control unit 168 over line 178. The address portion of the 
memory request is calculated by address generator 196 

25 (discussed later) and transmitted to virtual translation/FIFO 
control unit 200 over address generator address line 214. The 
address is translated, if necessary, to a physical address by 
virtual translation/FIFO control unit 200 in a manner 
described in the related Applications. The address is then 

30 sent to memory address and control unit 168 over physical 
address (PADRS) line 216. After receipt of the physical 
address from virtual translation/FIFO control unit 200 and the 
read/ write request from flow control unit 164, memory address 
control unit 168 transmits the memory address and the request 

35 information over memory address bus 12.4 to main memory 140. 
The requested data is returned over a memory data bus 122 to 
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memory data buffer 169, which in turn transmits the data to 
pixel SLU 172 for processing by a command executed by address 
generator 196 . 

In sum with reference to Figure 1, access requests by the 
5 graphics processor portion 210 (of graphics control unit 130) 
are transferred directly to memory control portion 220, by 
signal lines 165 comprising request line 212 and address line 
214 of Figure 2. Such direct transfer avoids access requests 
having to be transmitted over the system bus 120, memory bus 
10 structure 155 (containing memory buses 122 and 124), or I/O 
bus 170. 

It is noted, the method of memory access by graphics 
control unit 130 and the method of memory access by other 
system components both involve transmitting request 
15 information to flow control unit 164, and a memory address to 
memory address and control unit 168. It is again noted that 
the main memory access is executed in both cases without any 
action by processor unit 102. 

Continuing with Figure 1, graphics commands are 
20 transmitted from processor unit 102 as writes to a defined 
range of addresses in memory. The CPU 104 writes graphics 
commands and other writes to memory into a translation buffer 
106 for translation and formatting. Translation buffer 106 
then sends its contents to CPU bus interface 24 8 over CPU bus 
25 107. CPU bus interface 248 examines the addresses of the 
writes to memory to see if there are addresses in the range 
of addresses designated for graphics commands. If the write 
to memory contains a graphics command, CPU bus interface 248 
changes a bit in the request portion of the write to memory 
30 to indicate that the write to memory is a graphics command. 
The request portion of the write to memory is sent along an 
incoming portion of system request bus 113, where it is 
received by flow control unit 164 shown in Figure 2. Flow 
control unit 164 reads the bit that indicates that the write 



WO 93/04457 PCT/US92/07056 

15 

to memory contains a graphics command. Depending on a control 
field generated by virtual translation/FIFO control unit 200, 
flow control unit 164 signals memory address and control unit 
168 that the write to memory (graphics command) should be sent 
5 to one of three locations: (i) the FIFO command buffer 141 , 
which is a data structure residing in main memory 14 0, (ii) 
the PXDAT line as valid data for address generator 196, and 
(iii) FIFO residue buffer 324 where address generator 196 is 
currently unable to read new data. 

10 For case (i) above, the address in FIFO command buffer 

141 to which the graphics command is to be sent is calculated 
in the virtual translation/FIFO control unit 200 as follows. 
FIFO command buffer base register latch 310 stores the base 
address, i.e., the memory address of the beginning of the 64K 

15 byte block of memory where FIFO command buffer 141 resides. 
FIFO command buffer tail index latch 312 stores the number of 
FIFO positions between the base address of the FIFO command 
-buffer -and the tail, i.e., the next available position in the 
FIFO command buffer to which to write. The contents of the 

20 FIFO command buffer tail index latch 312 and the FIFO command 
buffer base register latch 310 are combined to yi^ld the 
memory address in the FIFO command buffer 141 to which the 
graphics command is to be sent. This address is provided to 
the memory address and control unit 168 which was previously 

25 signaled that the next write to memory is a write to FIFO 
command buffer 141. In turn, memory address and control unit 
168 transmits the computed address on memory address bus 124. 

The data portion of the write to memory, that is, the 
graphics command itself, is sent along an incoming portion of 
30 system data bus 112 to pixel SLU 172. Pixel SLU 172 sends the 
graphics command over memory data out line 218 to memory data 
buffer 169, which transmits the data on memory data bus 122 
to FIFO command buffer 141. 



When a graphics command is fetched from the FIFO command 
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buffer 141 for processing, the fetching is processed as a 
memory request. Virtual translation/FIFO control unit 200 
generates the address for the memory request and issues the 
memory request to the memory address and control unit 168. 
5 In particular , a FIFO command buffer head index latch 316 
stores the address of the next octaword to be read where 
command data is read from memory as aligned octawords. In 
this case, the next octaword to be read is the next -to-be-read 
command of the FIFO command buffer. The virtual 

10 translation/FIFO control unit 200 multiplexes and combines the 
contents of the FIFO command buffer head index latch 316 and 
the contents of FIFO command buffer base register latch 310. 
Virtual translation/FIFO control unit 200 transmits the 
resulting address on the physical address bus (PADRS) 216 to 

15 memory address and control unit 168, for transmission to the 
memory address bus 124. The fetched graphics command is 
returned from FIFO command buffer 141 on memory data bus 122 
to memory data buffer 169, and the pixel SLU 172 over MEMDAT 
line 187. Pixel SLU 172 in turn transmits the graphics 

20 command to address generator 196 over pixel data bus (PXDAT) 
188 or to the FIFO residue buffer 324 when address generator 
196 is unable to currently read new data. 



In executing graphics commands to draw to a window 
displayed on display unit 116, graphics commands (or sets 

25 thereof) are alternately fetched from FIFO command buffer 141 
and a clip list command buffer 145 (Figure 1) . Generally, if 
the graphics command fetched from FIFO command buffer 141 
indicates a clip list against which a "drawing unit" (i.e., 
a drawing command or set of drawing commands) is to be 

30 compared, virtual translation/FIFO control unit 200 records 
the current position in the FIFO command buffer 141 and 
switches command streams from FIFO command buffer 141 to clip 
list command buffer 145. Succeeding graphics command fetches 
for processing by address generator 196 are processed as a 

35 memory request similar to that described above but with 
reference to clip list command buffer 145 . 
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In particular, clip list command buffer 145 is another 
data structure residing in main memory 140. A clip list 
command buffer index latch 319 stores the number of clip list 
buffer positions between the base address of the clip list 
5 command buffer and the command of that buffer which is to be 
read next. A clip list command buffer base register latch 318 
holds the base address , i.e., the beginning address of the 64K 
byte block of memory where the clip list command buffer 145 
resides. The translation/FIFO control unit 200 

10 multiplexes/combines the contents of these two latches 318, 
319 to generate a request address, and issues a memory request 
with the generated address, to the memory address and control 
unit 168. In turn, the memory address and control unit 168 
transmits the memory request to main memory (i.e., clip list 

15 command buffer 145) via memory data bus 122 and transmits the 
memory request address on memory address bus 124. The fetched 
graphics command is returned from clip list command buffer 145 
on memory data bus 122 to memory data buffer 169 and the pixel 
SLU 172 over line 187. Pixel SLU 172 in turn transmits the 

20 graphics command to address* generator 196 over pixel data bus 
(PXDAT) 188. 

Accordingly, the clip list command stream is an 
alternative command stream to FIFO command buffer 141. As a 
result, each pattern or "drawing unit" is placed in the 

25 command stream only once, but is caused to be drawn in turn 
to each clip rectangle specified in the clip list. Thus, a 
common/same "drawing unit" for multiple clip rectangles of a 
clip list need only be stored once in the FIFO command buffer 
141. Further, drawing commands may also be placed in a clip 

30 list of clip list command buffer 145. This allows for a 
different block of physical or virtual memory (main memory as 
well as frame buffer locations) to be specified with each clip 
rectangle in the clip list. As such,* drawing to physically 
or virtually discontiguous blocks of memory can result from 

35 the same drawing unit. 
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Additional features for processing graphics commands 
through FIFO command buffer 141 and more generally for 
transmitting graphics commands from processor unit 102 to 
graphics unit 130 include a residue buffer 324 in pixel SLU 
5 172 and a short circuit logic in virtual translation/FIFO 
control unit 200. These features are understood to be 
incorporated in the foregoing operations of address generator 
196 during memory reads and writes as detailed in the cofiled 
Application. 

In the preferred embodiment the graphic commands support 
three basic kinds of drawing operations, namely, raster, text, 
and line operations . The graphics commands use three operands 
- SOURCE, DESTINATION, and STENCIL. Different graphics 
commands involve different combinations of these operands. 
For a given graphics command, the address generator 196 
formulates a virtual or physical memory address for the 
pertinent operands depending on whether the command includes 
virtual or physical memory information. The address generator 
196 places in latch "Next Address" the formulated memory 
address and a flag indicating whether the formulated memory 
address is a virtual or physical memory address. Latch "Next 
Address" is passed to virtual translation/FIFO control unit 
200 for translation into a physical memory address (where the 
formulated address is a virtual memory address) and for 
support of subsequent execution of graphics operations . 

The foregoing is accomplished by address generator 196 
in the preferred embodiment as follows and illustrated in 
Figures 3A through 3B. As shown in Figure 6, each operand is 
specified relative to a respective memory space. 
30 Specifically, a desired block of source data 8 9 resides within 
a source memory 95 . The beginning memory space position of 
source memory 95 is assumed to be the upper, left-hand corner 
shown. The desired block of source data 89 has a beginning 
address denoted (source__X, source_Y_base) , where source_X is 
35 the distance between the leftmost position of source memory 
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95 and the leftmost pixel position of source data block 89 
along a scanline (horizontal axis) . And source_Y_base is the 
first scanline of source data block 8 9 within source memory 
95. Similarly, a desired block of stencil data 90 resides 
5 within a stencil memory 99. The beginning memory space 
position of stencil memory 99 is assumed to be the upper, 
left-hand corner shown. The desired block of stencil data 90 
has a beginning address of (stencil_X, stencil_Y base) , where 
stencil_X is the distance between the leftmost position of 
10 stencil memory 99 and the leftmost position of stencil data 
block 90 along a scanline (horizontal axis) . And 
stencil_Y_base is the first scanline of stencil data block 90 
within stencil memory 99. 



As for the DESTINATION operand, a desired window 91 

15 resides within a destination memory such as frame buffer 
memory 151. User and client (application) operations 
involving the window 91, specify positions within the window 
91 relative to the upper, -left-hand corner (beginning address 
or origin) of the window instead of the upper, left-hand 

20 corner (beginning address) of the destination (frame buffer) 
memory 151. That -is, client/user virtual addresses -are -basea 
on a coordinate system with an origin at the first window 
position/address, whereas physical addresses are based on a 
coordinate system with an origin at the first position/address 

25 of destination (frame buffer) memory 151. To that end, window 
91 has a beginning address of (DEST_X_bias, DEST_Y_origin) , 
where DEST_X_bias is the distance between the leftmost 
position of window 91 and the leftmost position of destination 
(frame buffer) memory 151 along a scanline (horizontal axis) . 

30 DEST_Y_origin is the byte address of the first scanline of 
window 91 within destination (frame buffer) memory 151. In 
turn, a desired position (X,Y) within window 91 is referenced 
as (DEST_X, DEST_Y_base) , where DEST_X is the difference 
between the pixel position X and the leftmost position in 

35 window 91 along a scanline (horizontal axis) . DEST Y base is 
the byte address of scanline Y in window 91. The distance or 
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difference between DEST_Y_origin and DEST_Y_base is called 
DEST_Y_of f set and effectively equals tiie number, in bytes, of 
destination memory 151 scanlines from the first scanline of 
window 91 to the scanline of the desired (X,Y) position. 

5 For each operand memory space (source memory 95, stencil 

memory 99 and destination memory 151) , the width of the memory 
space (i.e., the total number of bytes along the length of a 
scanline in the memory space) is specified as a Y_step for 
reasons described below. 

10 Referring to Figure 3A, for each operand, address 

generator 196 employs a Y_Base address register 31, a Y_step 
register 41, an X_Bias register 33, and an X -position (DEST_X) 
register 35. The DESTINATION operand also has a Y_origin 
register 2 9 shown in broken lines which holds the value of 

15 DEST_Y_origin . The Y_Base address register 31 holds the 
linear longword address (i.e., the location in main memory 140 
or frame buffer 151) that corresponds to the first pixel of 
the first scanline to be accessed in the operand memory space 
by the graphics command being processed. This is the address 

2Q that corresponds to source_Y_base wnere the operand is- SOURCE, 
stencil_Y_base where the operand is STENCIL, and DEST_JY_base 
for DESTINATION operands. The Y_Base address register 31 also 
holds the Y_step value for the operand memory. Preferably, 
this value is a 14 -bit long twos complement number which is 

25 initially held in the Y_step register 41 and subsequently 
added to the Y_JBase address register 31. To that end, the 
Y_step register 41 allows for variable scanline width (Y_step) 
per operand. Accordingly, the address generator 196 maintains 
the byte address of the beginning of the current scanline 

30 (Y_base) for each of the operands as well as the byte address 
of scanline 0 for the destination operand (DEST_Y_origin) . 

The X_Bias register 33 holds the value of DEST__X_bias 
when the subject operand is DESTINATION; a source_X_bias value 
when the subject operand is SOURCE; and a stencil_X_bias value 
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when the subject operand is STENCIL . These values (DEST__X- 
__bias, source__X_bias, and stencil_X_bias) are provided to 
address generator 196 along with Y_base and Y_step values from 
different graphics commands as made clear later. The source- 
5 _X_bias value is computationally equal to the value of 
source__X minus the value of DEST_X. In a like manner, the 
stencil_X_bias value equals the value of stencil X minus the 
value of DEST_X. As such, source_X_bias and stencil_X_bias 
are values which when added to the destination X (DEST_X) , 

10 give the X position in the source and stencil operand spaces, 
respectively. DEST_X_bias is similarly a value, which, when 
added to the destination X position (DEST__X) , gives the actual 
X or pixel offset from the beginning of the destination 
scanline. Preferably, the value held by the X_Bias register 

15 33 is 16 bits long and in twos-complement format. 

Accordingly, for all drawing (graphics) commands, address 
generator 196 states the addresses of operands relative to the 
Y_Base and X_Bias as follows: 

operand address = operand Y_base + DEST_X + operand 
20 X_bias 

where "operand" in the above equation is source, stencil or 
DEST, and each of the values on the right-hand side of the 
equation are held in respective registers. 

In addition at command load time, the following registers 
25 are loaded based on an offset value provided in the command 
plus the contents of the Y_origin register 29: 

DEST_Y_base = DEST_Y_origin + DEST_Y_of fset; 
clip_Y_min = clip__Y_min_of f set + 'DEST__Y__origin; 
clip_Y_max = clip_Y_max_of f set + DEST_Y_origin 

30 where the Y min offset and Y max offset values are held at 
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register 67 (Figure 3B) discussed later. 

The above enables windows to be moved around memory and 
the display screen relatively easily. Changes to the base and 
bias registers 31, 33 are accomplished through setup commands 
5 discussed later. 

Referring back to Figure 3A, the X-position or DEST_X 
register 35 keeps track of the X coordinate (pixel position) 
within the current scanline of the DESTINATION operand, 
relative to the left edge of the involved memory window as 

10 established by the combination of DEST_X_bias and DEST_Y_base. 
That is, the DEST__X register 35 is a counter which counts 
pixel positions starting from the first pixel position of the 
graphics command. This is accomplished by the DEST__X value. 
Preferably, the DEST_X register 35 holds this value as a 

15 16 -bit, twos -complement number. Further, in the case of 
graphics commands for certain raster operations, a 16-bit 
initial X-Position register 37 is used for storing the frame 
buffer memory location corresponding to the first pixel 
position needed for each scanline of the raster operation. 

20 In sum, to provide the memory address of an operand read 

from a graphics command, address generator 196 adds the 
contents of the XJBias register 33, the DEST_X register 35, 
and the Y_Base address register 31. The sum of the contents 
of the X_Bias register 33 and the DEST_X register 35 provides 

25 the current address of the subject operand relative to its 
Y_Base address. Thus, the addition of the contents of the 
Y_Base address register 31 provides the memory address of the 
operand in terms relative to the beginning of the operand 
memory. For monochrome displays, the sum of the contents of 

30 the X_Bias register 33 and the DEST_X register 35 are shifted 
right three bits (as by shifter 43) before being added to the 
contents of the Y_Base address register 31. This results in 
formulating the correct byte address. For color displays, the 
sum of the contents of the X_Bias register 33 and the DEST_X 
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register 35 are not shifted before being added to the contents 
of the Y_Base address register 31. 

Address generator 196 then stores the results of the 
foregoing addition in a "Next Address" latch 39, Also 
5 provided in the "Next Address" latch 3 9 is a two-bit code for 
indicating whether the stored address is a physical memory 
address or a virtual memory address. In the preferred 
embodiment, address generator 196 sets the two-bit code to 00 
to indicate that a physical memory address is stored, and sets 

10 the two-bit code to 01, 10, or 11 to indicate that the stored 
address is one of three virtual addresses - DST, SRC, or STL, 
respectively. (DST refers to Destination; SRC refers to 
Source; and STL refers to stencil.) The address generator 196 
passes the "Next Address" latch 39 to virtual translation/FIFO 

15 control unit 200 to effect (execute) the graphics command with 
the data located at the memory addresses formulated by address 
generator 196. 



In a multi-operand raster operation, corresponding pixels 
in the respective operands reside at different X coordinates 

20 (pixel position within a scanline) in their respective 
address spaces /memories . Furthermore, the drawables 

associated with each operand of a graphics command may have 
different byte or word alignment. Therefore, a mechanism is 
needed to normalize the operands of a graphics command to a 

25 single X address space relative to the memories in which the 
operands reside . 



This is accomplished in the present invention by the 
pixel bias value provided for each operand in X Bias register 
33. As discussed above, the pixel bias value is defined as 
30 the number to add to the current X drawing coordinate 
(X-position or DEST__X) to find the memory address 
corresponding to the subject pixel for each operand. The 
setup commands (discussed later) establish these bias values, 
taking into account both memory alignment and the difference 
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between the source and destination X coordinate (pixel 
position) offsets • 

For example, in a monochrome operation assume a source 
operand, SRC, with the following attributes given in 
5 hexadecimal values : 

Y Base Address of Pixel 0,0 = 1000 
Bit Offset of Pixel 0,0 = 05 

Y Step = 200. 

Also assume a destination operand, DEST, with the following 
10 attributes: 

Y__Base Address of Pixel 0, 0 = 2000 
X_Bias Value of Pixel 0,0 « 01 

Y Step = 500. 

Given the foregoing, to accomplish the following copy command 
15 in monochrome: 

SRC_X: 100 

SRC_Y: 100 

DEST_X: 50 

DEST_Y: 50 

20 WIDTH: 70 

HEIGHT: 80 

The registers are loaded as follows: 
SRC__Y_Base = 1000 

SRC_XJBias = SRC_X + SRC bit offset - DEST_X = 100+5-50 

25 = 55 

DEST_Y_Origin = 2000 
DEST_X_Bias = 1 

SRC Address = (SRC_X_Bias + X DRAW)<16:3> + SRC_Y_Base 
= (55 + 50)<16:3> + 1000 
30 DEST Y Offset = DEST_Y * Y_Step = 50 * 500 = 25000 
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DEST_Y_Base = DEST_Y_Origin + DEST_Y_Of f set = 2000 + 
25000 = 27000 

DEST Address = (DEST_X_Bias + X DRAW) <16 : 3> + DE S T_Y__B AS E 
= (1 + XDRAW)<16:3> + 27000. 

5 The address generator 196 of the present invention 

supports (i.e., provides addressing for) graphics commands 
for raster operations to effect graphics drawing primitives 
(other than vectors) , tile and stipple strips , stencils , and 
glyph bitmaps as follows . With reference to tile and stipple 

10 strips, strip implies that the source and destination have the 
same number of scanlines . Arbitrary sized tiles and strips 
are supported by address generator 196 and hence graphics 
control unit 130. The restrictions are that the source must 
be or expanded to be at least one octaword (16 bytes) in 

15 length, and it must be octaword aligned. The tile or stipple 
can be padded with multiple complete copies. Odd sized tiles 
and stipples force the destination operand to be accessed 
twice when the tile or stipple ends and is then read again. 

Stipples can either be a contiguous bit stream -or -a 
20 bit-per-pixel bit stream. A Source Plane Index held in 
register 45 (Figure 3B) specifies which plane (bit depth) is 
to be used. Transparent stipples are also supported by 
graphics control unit 130. The stipple bits which select the 
foreground and background registers 65, 73 (variables) are 
25 routed to a masking logic for selecting the DESTINATION 
operand whenever the bit is clear. The stipple bits are 
logically ANDed with a Write Plane Mask 47 and STENCIL operand 
if enabled. The resulting mask selects between the Pixel SLU 
172 and the DESTINATION operand at the bit level for main 
30 memory accesses. 

Graphics control unit 130 also supports raster operations 
Span and Continue Span graphics command packets for complex 
operations . A Span is the raster operation function for a 
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scanline. Trapezoids and tiled or stippled vectors are 
accomplished with, raster operation Span and Continue Span 
command packets . The Continue Span command packet directs the 
address generator 19 6 to update the base address register 31 
5 with the next scanline linear longword address , and supplies 
a new initial X-Position and X count for the DESTINATION 
operand. The source/stencil operands are specified with each 
graphics command data packet. The source/stencil operands are 
already set up before the first raster operation Span packet 
10 and are updated for each scanline by the address generator 
196. Addressing for each operand is then performed by address 
generator 196 as described above with reference to Figure 3A. 

Figure 3B illustrates address generator support of the 
foregoing commands in a preferred embodiment. The Write Plane 
Mask 47 specifies the planes which are to be modified when 
writing to the DESTINATION operand. The Source Plane Index 
register 45 specifies the plane (depth bit) of interest for 
referencing a single plane from a multiplane operand as the 
source. The input of a funnel shifter 51 is fed by either 
graphics data buffer 204 or the STENCIL operand. The STENCIL 
operand has a one longword residue latch 53 before- funnel- 
shifter 51 and one mask buffer 55 at the output of the funnel 
shifter 51. The STENCIL operand is fed through the funnel 
shifter 51 for aligning with the DESTINATION operand. A 
quadword (64 bits) is required to result in a longword of 
STENCIL for masking. When used for color, four bits are used 
for each longword and sixteen bits for an octaword. A 
longword of the STENCIL operand is fetched every two 
DESTINATION accesses for color pixels. 

30 When the DESTINATION is a contiguous single plane 

operand, i.e., a monochrome bit map, then the destination 
accesses are limited to a single longword (32 pixels) ; and 
a longword of the STENCIL operand is fetched between every 
destination access . 
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Address generator 196 requests an octaword (128 bits) for 
the Source data and loads it into the graphics data buffer 204 
through PXDAT line 188, When the data is read from main 
memory 14 0, the data is checked for correct parity and 
5 corrected. The contents of graphics data buffer 204 are 
funnel-shifted down to sixteen bits in preparation of 
processing in pixel SLU 172 with the destination data. The 
first access on a scanline accesses two octawords to ensure 
the presence of the correct amount of data for one octaword 
10 destination access. If source and destination are perfectly 
aligned, then one octaword is accessed. At any event, 
octawords are accessed for pipe line processing through GDB 
204 and SLU 172. 

The shift amount in the funnel shifter 51 is determined 
15 by the SOURCE address, Source Plane Index , and DESTINATION 
address . The beginning of the source data must be aligned 
with the beginning of the destination. The source must also 
be wrapped when it is smaller than the destination. The X 
dimension (pixel position) is wrapped for tiles and stipples. 
20 The wrapping occurs by reading the source a second time and 
performing two operations on the same destination data with 
the appropriate masking applied. 

Funnel shifter 51 is basically a multiplexer. To that 
end, funnel shifting is accomplished by multiplexing the 
• 25 output of graphics data buffer 204 and selecting the 
appropriate byte from each longword. The first stage of the 
funnel shifter 51 shuffles the bytes to the appropriate 
position for the bit shifter which follows. The bytes are 
shuffled for both right -to-left and left -to-right shifting. 
30 The bit shifter shifts from left to right 0 to 7 bits. This 
works for both monochrome and 8-plane color. It also allows 
planes to be moved. 

The pixel SLU 172 is a 32-bit wide logic unit. Data is 
pipelined, and control is clocked every one-half cycle for 
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providing an effective throughput of one longword every cycle. 

The address generator 196 requests a destination octaword 
(12 8 bits) read-modify-write or just a write, depending on the 
Boolean function and the destination (main memory 14 0 or frame 
5 buffer 151 . The memory data input of pixel SLU 172 receives 
the destination data into register 57. A 16-bit, 4-to-l 
multiplexer 59 for selecting the appropriate word receives 
from register 57 the destination data. The multiplexer 59 
feeds both the Pixel SLU 172 and the funnel shifter 51. The 
10 Pixel SLU 172 makes two passes at the data with shifting both 
the source and destination data and writing a word into the 
32-bit output latch 61. The output latch 61 is two longword 
latches which act as a double-buffered longword latch. 



The masking operation to frame buffer 151 of the written 
15 data is taken care of with write plane mask registers 47. 
The write mask register 47 contains a byte mask for internal 
bytes and begin and end bytes for the byte boundaries for both 
edges of the raster operation. The boundary bytes are 
generated with the instruction of the address generator 196 
-2D which contains the address and pixel count. When a third 
(STENCIL) operand is used, the third operand is logically 
ANDed with the plane mask 47 for generating the correct mask 
with write-only operations. This only works for longword 
accesses. Accesses which are larger than a longword and have 
25 edge masks are performed with read-modify-write operations . 
When a read-modify-write operation is in process, then the 
ANDed mask becomes the multiplexer select between the pixel 
SLU 172 and the destination data. De-asserted bits select the 
destination data. Raster operations to main memory 140 
30 perform read-modif y-writes for performing the plane masking. 

Scrolling and window moves are accomplished by using two 
operand raster operation command packets . A typical case 
described here is a two-operand raster operation which 
requires both the Source and Destination command packets. 
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Other cases involving source and destination command packets 
are understood to be similarly handled. No special case data 
packets are supported, since all operations can be either to 
the display screen or to virtual memory as well as physical 
5 memory. Operand addressing by address generator 196 is as 
described above. The registers used in the preferred 
embodiment are DST and SRC Y_Base registers 31, DST and SRC 
Y_step registers 41, DEST__X register 35, initial X-Position 
register 37, DST and SRC X__Bias register 33, DST X count, 
10 Initial X count and Y count. 

The data moves to and from graphics data buffer 204 with 
octaword accesses. Data moves through the Source path of the 
Pixel SLU 172. As the data is moved, it is shifted, 
inverted, or left alone. The plane mask 47 is used on writes 
15 to the frame buffer 151 with write octawords, and octaword 
read-modify-writes with the plane mask 47 is used to main 
memory 14 0. 



Two modes are supported for text, transparent (masked) 
and opaque (unmasked) . If transparent text is desired, then 

20 all de-asserted bits disable the writing of the appropriate 
pixels. The asserted bits are written with the foreground 
color for color displays. The mask logic takes care of the 
disabling of the writes. The font is loaded into the third 
operand of the raster operation data packet. This operand is 

25 logically ANDed with the plane mask 47 and selected on a bit 
basis with the destination operand or the Pixel SLU 172 . This 
is performed for both one and eight bits per pixel, i.e., 
pixel depths of one bit and eight bits . When opaque 
characters are used, then the bit selects between two colors, 

30 foreground or background, for color displays. This 
functionally resides within the Pixel SLU 172. Also, any 
glyph data is loaded into the SOURCE operand. Unlike any 
other source, the scanlines of the glyph can be of an 
arbitrary width in bits . Tiled text is supported by first 

35 rendering the text to a temporary bitmap, and subsequently 
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using the result as an input to the STENCIL operand, while 
supplying a tile pixmap to the SOURCE operand. 

The text source data is read from either main memory 140 
or frame buffer 151. It is passed through the Pixel SLU 172 
5 and stored into an octaword block data buffer. The octaword 
data buffer 204 then presents the appropriate bytes to the 
funnel shifter 51 which provides the shifting down to two bits 
for the color selection. The text can be a linear source 
operand and a different or the same shape as the destination 
10 memory space. The X_Bias registers and X-position counter 
(DEST_X) are used as described above. 

Rectangle fill is accomplished with either one, two, or 
three operand raster operations depending on whether the fill 
is solid, tiled, stippled, stenciled, and/or a combination of 

15 tiled, stenciled, stippled, and copy. The description below 
describes the flow for this particular application of graphic 
control unit 130. Solid colored or stippled rectangle fills 
are accomplished by unloading the graphic data buffer 204 with 
an arbitrary pattern and number of bits from either the host 

20 or main memory. The -data buffer 204 acts as the source for 
filling a rectangular portion of either frame buffer 151 or 
main memory 140. The fill pattern wraps back on itself on a 
scanline-by-scanline basis . The data is either used directly, 
color expanded, or as both the source and mask for 

25 transparency . 

Vector or line drawing is supported by graphics control 
unit 130 using a modified Bresenham scheme. The registers 
used for formulating operand addresses described above in 
Figure 3A of the address generator 19 6 are utilized for 
30 vector drawing but with different contents. Three 16-bit 
registers of Figure 3A are required for error calculations 
in vector drawing which direct the X and Y__steps for drawing 
the desired line. In particular, the Stencil X_Bias register 
33 is used as an error accumulation register. The initial 
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X-Position register 37 is used as a primary error register, 
and the Stencil Y_step register 41 is used as a secondary 
error register. 



In one embodiment of the present invention, the Source 
5 addressing registers are used for addressing a linear operand 
for patterned (dashed and dot) vectors/lines. The Source 
operand may be color-expanded if desired. Two-dimensional 
tiled and stippled vectors are not supported here. 
Three-operand vectors are also not supported in vector/line 
10 drawing by graphics control unit 130. In another embodiment, 
tiled, dashed and stenciled lines are drawn one pixel at a 
time . 



The positive and negative Y_step registers (Figure 3A) 
are loaded with 14-bit twos -complement Y-scanline steps. The 
15 positive or negative Y_step register is sign extended and 
added to the destination Y__Base address register 31 dependent 
on the error accumulator register's (Stencil X_Bias 
register's) most significant bit. 

The X-position count or DEST_X register 35 is loaded with 
20 the starting X pixel coordinate relative to the window or 
pixel map. The DEST_X register 35 is added to the positive 
access size, negative access size in pixels (1 or -1 or 0), 
and updated in parallel with the forming of the new 
Destination Y_Base address register 31. That is, the 
25 X-position count (DEST_X register) 35 is incremented, 
decremented, or remains unchanged, depending on the octant of 
the vector being drawn and the most significant bit of the 
error accumulator register (Stencil XJBias register 33) . The 
incrementing/decrementing depends on the setting of an 
30 X_backward (Y_backward) bit in the graphics commands described 
later. 



The contents of the Next Address latch 39 is the latched 
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sum of the DEST__X register 35 , operand X_Bias register 33 , and 
the operand Y_Base address register 31 as described above. 

The error accumulator register's (Stencil X_Bias 
register's) most significant bit also selects between the 
5 16-bit, twos -complement contents of primary error and 
secondary error registers (initial X-Position register 37 and 
Stencil Y_step register 41) , respectively. 

The operand addressing is pipelined for enabling the 
calculation of the next address, check for last pixel, window 
clip, and virtual address comparison, to occur in parallel 
with the addressing of the present pixel. The pixel size is 
within an address generator control register for helping the 
graphics control unit 130 determine the number of bytes which 
must be read and written. The DEST_X (X-Position) and X_Bias 
registers 35, 33 provide an address to either the bit for 
monochrome or byte for eight -plane color, respectively. 

For zero-length vectors, graphics control unit 130 draws 
no points on the Destination space (i.e., main memory or 
screen view of display device 116) . Vectors of length 1 are 
drawn with one pixel and no registers other than the 
destination base address register 31, X-Position register 35, 
and the vector length counter 63 need to be loaded. 
Typically, the data for flat-shaded vectors is supplied to the 
Pixel SLU's 172 foreground latch 65 with the pertinent logical 
function . 

The address generator 19 6 supports window-clipping 
rectangles . The window-clipping rectangle functionality is 
usable for graphics commands to both the frame buffer 151 and 
main memory 140. In a preferred embodiment of address 
30 generator 196, there are four clipping rectangle registers, 
X minimum, Y minimum offset and X maximum, Y maximum offset 
illustrated at 67 in Figure 3B. Y__offsets are used to enable 
implementation of multiplication without a multiplier device. 



10 



15 
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More importantly, Y_offsets are used so that the actual 
drawing commands are unbound from the location of the 
destination memory. Therefore, the destination memory origin 
can be reloaded via a clip list, but the same set of drawing 
5 commands can be executed to multiple destination operands. 

The window clipping rectangle is loaded with the linear 
longword addresses for the Y coordinate for the upper and 
lower left corner of the destination window, screen, or pixel 
map. The Y registers are compared to Y comparator 71 r the Y 
10 registers and comparator preferably being 28 bits each. The 
X values are relative to these longword addresses . The X 
registers and comparator 69 are preferably 16 bits each. 

Two comparators 69, 71 are used twice per destination 
access which check for four edges of the rectangle. Writing 

15 occurs when the address is within the rectangle as determined 
from the X, Y minimum and X, Y maximum established from 
registers at 67. The X comparator 69 checks multiple pixels 
at a time, e.g., 16 for 8 plane and 32 for monochrome. This 
means that monochrome or continuous single-plane operations 

20 are performed one longword (32 pixels) at a time, while color 
is operated on an octaword (16 pixels) at a time. 

Accordingly, clipping is executed such that a series of 
single scanline operations (i.e. points or spans) result in 
the same series of Y addresses, regardless of the location of 
25 the clip rectangle. 

Now turning to the command set of the present invention. 
The command set is optimized to support low-level software 
drawing algorithms efficiently, as discussed next. In order 
to allow low-level graphics software algorithms to operate 
30 efficiently, the present invention command set has the 
following characteristics: 



(1) very small packets for point, pixel, and span 
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commands. This presents the same or less cost for drawing 
individual pixels as a "dumb" color frame buffer. 

(2) Y-update modifier, for supporting "stepping" or not 
"stepping" in the Y (scanline) direction for Bresenham or 

5 other algorithms across all operands. 

(3) X-update modifier, for supporting "stepping" or not 
"stepping" in X (pixel position) direction for Bresenham 
algorithms . 

(4) No-draw modifier, for supporting updating internal 
10 addresses without drawing. Used in dash algorithms. 



(5) Y-backwards modifier, for causing all internal Y- 
addresses to be decremented instead of incremented. 



(6) X-backwards modifier, for causing internal X- 
addresses- to be decremented instead of incremented. 

15 (7) DEST-relative addressing (destination-relative 

addressing) . That is, address generator 196 computes the X 
address of the SOURCE and STENCIL operands automatically using 
the DESTINATION address X, as previously detailed. 



(8) Preservation of internal state for: 

20 (a) current destination scanline 

(b) current destination pixel position X 

(c) current source scanline 

(d) current stencil scanline 

(e) current source X-bias 
25 (f) current stencil X-bias 



Preservation of this state is accomplished by 
registers in Figures 3A, 3B holding respective values until 
modified by pertinent graphics commands . By retaining this 
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state, the present invention makes it unnecessary for this 
information to be respecified in graphics commands for a 
trivial draw operation. For example, it is possible to draw 
a stenciled, tiled circle by supplying a stream of [X, width] 
5 pairs. 

(9) FG/BG modifier, for allowing selection of the 
foreground or background color of a display without explicitly 
reloading a color. 

(10) Ability to modify foreground and background colors 
10 as part of a pixel drawing command. This supports continuous 

tone operations, where a sequence of adjacent pixels all have 
different values generated by the algorithm. 

(11) Short-circuit FIFO support. This eliminates FIFO 
memory traffic overhead which is significant relative to the 

15 drawing memory traffic for these trivial operations. 

With regard to another aspect of the present invention, 
• the Destination operand address and other contextual 
information supporting a - graphics command are established 
independently and separately from the actual desired 

20 operation. To that end, for a sequence of graphics commands 
with a common context, the context only needs to be specified 
one time for the sequence instead of one time for each 
graphics command in the sequence. Further, the contextual 
information of a desired graphics command is organized in 

25 independent parts for allocating foreground color, background 
color, plane mask, logic unit function, destination/clip 
rectangle (or alternatively clip list) and desired operation 
(in single plane or multiplane) . To that end, each 
independent part may be changed individually while retaining 

30 previous allocations for the other parts such that only the 
changed part is respecified within a sequence of graphics 
commands . 
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Said another way, frequently sequences of graphics 
commands consist of operations that are repetitive and in 
which the context of the command varies in a repetitive or 
easily calculated way from the context of the previous 
5 command, or does not vary at all. Some graphics systems 
recognize this fact by having graphics context commands. 
However, each graphics command updates many elements of 
graphics context that do not need updating. The present 
invention provides setup graphics commands (distinct from 
10 raster drawing/ operation graphics commands) that are of finer 
granularity than that in the prior art (and in particular than 
that in packet -based interfaces) , such that updating occurs 
only to elements that have changed. 



More generally, in graphics commands, it is frequently 

15 not necessary to send all the fields of a command. The 
information contained in some of the command fields may be 
redundant, or not necessary. Since sending this information 
generates bus traffic, it is desirable to send only necessary 
information over the bus . The present invention accomplishes 

20 this by enabling each graphics command to have one length when 
transmitted a .first. time and thereafter a potentially shorter 
length when transmitted a subsequent time within a common 
series or sequence of graphics commands. In particular, the 
format of the graphics commands includes multiple fields 

25 arranged in the same order from one command to the next. The 
values of certain fields of the graphics commands are held in 
reS p ec tive memory registers, unchanged until respecified in 
subsequent graphics commands. Those fields are positioned in 
an omittable end portion of the graphic command (i.e., in a 

30 last valid word, byte, or other logical unit of the graphics 
command) . In the preferred embodiment the order of these 
fields is organized so that the most frequently used fields 
are near the beginning of the command format. Each of the 
possible fields of a graphics command of the present invention 

35 is detailed next with reference to Figures 5A through 5R. 
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The general graphics command 77 format is illustrated in 
Figure 5A with a header 75 as the first longword (32 bits) and 
three succeeding longwords 77 reserved for data dependent on 
the graphics command specified in the header. The first eight 
5 bits of the header 75 are allocated for operation codes 87. 
The succeeding two bits form a length field 81 which encodes 
* the number of longwords which succeed the header and carry- 

valid information. A six-bit flag field 83 includes (i) 
operation-dependent flags that are generally examined by the 
10 address generator 196 in specific data flows relating to the 
operation code 87 and operation set-up "action" flags , 
described later , and (ii) FIFO command buffer 141 flags used 
to implement clip list processing. The latter flags are 
provided for most graphics commands which are expected to 
15 occur in the clip list and for those that begin or end a "draw 
unit" (discussed later) in the FIFO command buffer 141. 
Further , the FIFO control flags are handled directly by the 
FIFO command buffer logic in virtual translation/FIFO control 
unit 200. When these bits 83 are not used for FIFO control 
20 flags, they are available as additional flags (e.g. halt, 
interrupt and wait/svnchronization flags) to the address 
generator 196. The last sixteen bits of header 75 provide 
operation-code-dependent data 85. 



Figures 5B through 5D illustrate graphics commands for 
25 raster or drawing operations of particular interest, namely 
ROP_RECT, ROP_POINT and PIXEL. The ROP_RECT command is used 
to draw an arbitrary rectangle to either physical, virtual 
memory or to I/O space. The ROP_POINT and PIXEL commands 
perform identically to ROP__RECT except in only drawing a 
30 single pixel or point. 

Figure 5B illustrates the graphics command format for the 
ROP_RECT graphics command. This graphics command starts a 
raster operation for a rectangle, strip, or span. This 
command is also used for one-, two-, and three-operand raster 
35 operations as well as tile and stipple operations . The 
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operation that is performed depends upon the value of the 
action field in an associated 0P_SETUP command set forth 
later. 

The command format illustrated in Figure 5B shows the 
operation code R0P_RECT in the most significant eight bits of 
header 75. The length bit indicates that two additional 
longwords follow the header 75 for this command. A Y_backward 
flag if set in flag field 8 9 causes respective Y-step values 
to be subtracted rather than added to the scanline addresses 
for each operand. This causes the raster operation to 
progress from bottom to top rather than the usual top to 
bottom of the operand memory spaces . An X__backward flag if 
set in field 83 enables copy to move from right to left across 
each scanline. In a copy operation , the X_jbackward flag only 
needs to be set if the source and destination share the same 
starting scanline and the source is to the left of (smaller 
x) the destination. 

It is sometimes convenient to draw twice on the same 
scanline. The Y_NO_UPDATE flag is used for this purpose. 
20 When this flag is clear (not set) , the SCANLINE ADDRESSES -for 
each of the operands is updated by the Y-step associated with 
that operand. Preferably, the Y_NO_UPDATE flag is used with 
point or span algorithms when the subsequent draw operation 
is to occur at the same Y coordinate. Without this flag, it 
25 would be necessary for the software to shadow SCANLINE 
ADDRESSES for each operand and re-execute operand setup 
commands every time it was necessary to suspend progression 
in Y. 

Flag field 8 9 also holds clip control codes described 
30 later. 

The least-most significant 16 bits of the header 75 store 
the destination X at which the rectangle should be drawn, 
i.e., the X coordinate, in the destination coordinate space, 
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of the first pixel in the destination to be modified. This 
field (DEST_X) is undefined after most raster operations. 



In the longword that succeeds the header 75 , width (the 
number of pixels in X that should be filled) and height (the 
5 number of pixels in Y that should be filled) information are 
provided. In the third longword of the ROP_RECT command 
format, an offset value is stored. The offset, in bytes, is 
defined as the distance between the SCANLINE ADDRESS of the 
first scanline to be drawn and the origin of the destination 

10 supplied in the DEST_SETUP command packet. The address 
generator 196 calculates the initial DESTINATION SCANLINE 
ADDRESS as (DEST_Y_OFFSET + DEST_Y_ORIGXN) prior to executing 
the raster operation. This offset is used instead of an 
address so that the same sequence of clip entries can be 

15 executed against multiple destination memories. 

Algorithms which output sequential spans can be 
implemented with the two longword variant of the ROP_RECT 
command illustrated in Figure 5B. At the end of -each ROP_RECT 
command, all three of the active operand SCANLINE ADDRESSES 

ZD are updated internally by graphics control unit 130. The 
starting SCANLINE ADDRESSES need only be established once at 
the beginning of the series of vertically adjacent spans. 
Each additional span requires only the X-Position, width, and 
height ~ 1. However, span and point algorithms which rely on 

25 internal SCANLINE ADDRESSES must take care that the starting 
SCANLINE ADDRESSES are re-established once per sequence of 
commands (called a drawing unit discussed later) as the entire 
sequence of commands on the clip unit is re-executed (as 
discussed later) . 

*■ 

30 The ROP_RECT command has the following relationship to 

SOURCE and STENCIL operands. If SOURCE and/or STENCIL 
operands are in use, the new SCANLINE ADDRESSES for these 
operands must be established prior to any raster operation 
data packet which includes a DEST__Y offset. This is required 
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to set the corresponding SCANLINE ADDRESSES . The source setup 
command packet must reset the tile, pixmap, SCANLINE ADDRESS 
once every tile height scanline in one embodiment of the 
present invention . 

Illustrated in Figure 5C is the command format for the 
ROP__POINT graphics command. The ROP_POINT graphics command 
executes the same function as ROP_RECT, except that height and 
width are assumed to be 1 and do not have to be passed 
explicitly. It is intended for use by software algorithms 
which emit points of the same color. Each pixel drawn 
typically requires a single longword written to the FIFO 
command buffer 141. Software retains control of address 
generation but can exploit the shifter 51, Pixel SLU 172, and 
some of the internal adders to advantage. Examples of 
algorithms which may be rendered with this command are tiled, 
stippled, stenciled, and dash lines and arcs. 

Referring to Figure 5C, the header 75 provides an eight- 
bit operation code indicating the ROP_POINT command. The 
header also provides six flags in flag field 83 as follows: 

20 A NO DRAW flag, when set, inhibits destination 

modification but does not affect internal scanline address 
updates. The NO_DRAW flag is intended for use in drawing 
on/off or dashed lines where alternate segments of the dashed 
lines pattern are not to be modified. Executing a ROP_POINT 

25 command with the N0_DRAW flag asserted accomplishes the 
SCANLINE ADDRESS updates on up to three operands . 

- An X_UPDATE flag, when set, causes the DEST X field 93 
to be incremented or decremented by one after the draw 
operation; 

30 - A USE BG flag, when set, draws with the background 

pixel value instead of the foreground pixel value; and 
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- The X_backward, Y__backward and Y_no__update flags as 
described in Figure 5B. That is, the Y_NO_UPDATE flag allows 
drawing more than one pixel to a scanline. The Y_JSJO_JJPDATE 
and X_UPDATE flags result in the orderly update of the 
5 destination X and the destination Y offset registers so that 
lines and arcs can be optimized for command bandwidth. 

The length field of the header indicates that, at most, 
only one longword follows the header 75 . In that succeeding 
longword is the Y destination offset in bytes, similar to that 
10 described in Figure 5B. 

The ROP__POINT graphics command allows the address 
generator logic to concentrate on the destination address 
generation. The combination of normal CPU write buffering and 
the FIFO command buffer 141 allow the CPU to queue ROP_POINT 
15 and PIXEL commands without -waiting on memory. The 
applications of ROP_POINT, and PIXEL commands could also be 
implemented by accessing the frame buffer 151 directly. 
However, direct frame-buffer access has the following 
di s advant age s . 

20 (1) need to synchronize with previously queued drawing 

commands; 

(2) need to stall CPU to wait for frame buffer reads and 
writes; 

(3) complexity of managing tile and stencil operands; 

25 and 

(4) need to handle clipping in software instead of 
through clip list buffer 145. 



30 



Figure 5D illustrates the PIXEL command format. The 
PIXEL graphics command is likewise similar to the ROP_RECT 
command except in the area of data packet loading. The PIXEL 
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command has only one parameter. That parameter is a pixel 
color value which is loaded into either the foreground or 
background registers 65, 73 (Figure 3B) . The destination X 
and Y values are assumed to still be valid from the last 
5 command executed. To that end, the PIXEL command is for 
scanline algorithms which emit pixel values as they move 
across a scanline. 

Referring to Figure 5D, the most significant eight bits 
of the header 75 of the PIXEL command indicates the PIXEL 

10 command operation code. The flags field 83 includes the 
NOJDRAW, X_update, USE_ BG, Y__backward, X_backward, and 
Y_NO_UPDATE flags described above. The length field indicates 
that one longword follows the header. The least significant 
16 bits of the header 75 contains a pixel value to load into 

15 the foreground or background register 65, 73 (Figure 3B) prior 

to drawing when the NO DRAW flag is set. For eight -plane 

destinations, this is simply an eight -bit pixel value. For 
one-plane (monochrome) destinations, the foreground/background 
registers 65, 73 are interpreted as eight adjacent pixels. 
20 • Therefore, the bit representing the foreground or background 
pixel values is .replicated eight times. That is r for one- 
plane destinations, the pixel field 97 contents is OXFF 
(foreground) or 0X00 (background) . 

The functionality of the pixel command may be 
25 accomplished with direct frame-buffer access from the CPU. 
However, this requires synchronization with previously queued 
commands, software clipping, stenciling and combinatorial 
logic, and makes poor use of the memory data paths. Using the 
pixel command is therefore preferred over direct frame-buffer 
30 access. 

It is noted that another graphics command must be used 
to establish the location of the beginning of a desired 
scanline. This is accomplished in a non-redundant way by 
using the ROP__POINT command in its two longword form 
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specifying DEST_X and DEST_Y_OFFSET only. Subsequent pixels 
require one single longword pixel command each. In addition, 
pixels may be skipped either by insertion of a one longword 
ROP_POINT command or by a PIXEL command with the NO_DRAW flag 
5 bit asserted. 



Additional raster drawing operations use glyph primitives 
and line primitives discussed in Figures 5E and 5F. Figure 
5E illustrates a command format for a ROP_GLYPH command. The 
ROP_GLYPH command is a specialized variant of the ROP__RECT 

10 command which fetches glyph bit maps in an optimal way. The 
present invention graphics system glyph bit maps are like 
other bit maps except that there is no interscanline padding. 
The dimensions of the glyph bit map are the minimum bounding 
rectangle for the inked area of the glyph. Direct support for 

15 packed glyph bit maps allows the graphics system of the 
present invention, in most cases, to read the entire glyph bit 
map in a single octaword read. Total memory traffic is nearly 
halved over -a di-screte read for each source scanline of the 
glyph. No direct support is supplied for image text. It is 

20 generally more efficient for the present invention graphics 
system to clear a whole line of text at once than to clear a 
single glyph. At the expense of some generality, the overall 
command format is defined such that no source setup command 
is required for rendering glyphs. This, in turn, reduces CPU 

25 load and FIFO buffer traffic. 



Referring to Figure 5E, the header 75 contains an eight 
bit operation code indicating the ROP_GLYPH command. A 
VIRTUAL flag 83, when set, indicates that the glyph address 
is a virtual address. Other flags include clip control codes 

30 in flag field 83 as discussed later. The length field in the 
header 75 indicates that three longwords follow the header 75 
in the ROP_GLYPH command. The DEST_X field (least significant 
16 bits) of the header 75 provides the X coordinate in the 
destination coordinate space of the first pixel in the 

35 destination to be written. The longword following the header 
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75 provides the Y OFFSET, in bytes , in the field indicated 

DEST_Y_OFFSET. 

The third longword of the ROP_GLYPH command has a height 
field and a width field. The height field provides an 
5 indication of height (in pixels) of the glyph as it will be 
drawn to the destination. The width field provides a width 
value (in pixels) of the glyph as it will be drawn to the 
destination. The width of the destination write is tied to 
the width of the glyph pix map. This, in combination with the 
10 bit map address, eliminates the need to supply a separate 
source setup packet. The fourth longword of the ROP_GLYPH 
command provides the byte address of the glyph bit map in the 
field marked GLYPH_ADDR. 

Figure 5F provides the graphics command format for the 
15 DRAW_LINE command. This command draws a thin, solid vector. 
The line primitive implements the Bresenham line drawing 
algorithm to give vector drawing rates that approach memory 
speed . 

The header 75 of the DRAWJLINE command provides an 
20 operation code (DRAW_LINE) in the leftmost field and an X 
coordinate in the destination coordinate space in the DEST_X 
field. The flags field 83 provides a Y_backward flag, an X- 
backward flag, and a Y_major flag among clip control codes 
(discussed later) . The Y_backward flag, when set, indicates 
25 that the starting Y coordinate of the line is greater than the 
ending Y coordinate. The X-backward flag, when set, indicates 
that the starting X coordinate of the line is greater than the 
ending X coordinate. The Y_major flag, when set, indicates 
that the line spans more pixels in Y than in X. The length 
30 field indicates that the command format contains a total of 
four longwords (three longwords succeeding the header 75) . 



The second longword carries the Y offset in bytes. The 
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third longword is formed of two fields , an e2 field and an el 
field. The el field indicates the increment to be added to 
a variable D when moving along the major axis. The e2 field 
provides the increment to be added to the variable D when 
5 moving along the minor axis. The value of the variable D is 
held in a first field of the fourth longword of the command. 
The variable D is an unsigned, 16-bit integer which overflows 
when it is time to move in the minor axis. A line length 
field is also provided in the last longword of the command. 
10 The line length field provides the number of pixels to draw. 

In addition to the raster operation commands, data 
packets of the present invention graphics system also include 
setup commands discussed next with reference to Figures 5G 
through 5K. It is these commands that provide setup and 

15 allocation operations used in forming the "context" for 
supporting the foregoing drawing graphics command or sequence 
of such graphics commands. The context includes "graphics 
context" and "clip context" parts. The PIXEL, 

LO^D_PLANE__MASK , and LOADJLUJFUNC commands of Figures 5D, 5G, 

20 and 5H provide "graphics context" operations, and DEST_SETUP 
and LOAD_CLIP (or SET_CLIP LIST) -commands of Figures 51 
through 5K provide "clip context" operations. The OP_SETUP, 
SOURCE_SETUP, and STENCIL_SETUP commands of Figures 5L through 
5N establish the desired operation to be performed and the 

25 source and stencil for carrying out that operation. Each of 
the foregoing context commands of Figures 5D and 5G through 
5N are independent from each other so that individual ones of 
these commands may be changed independent of the others . 
Accordingly, the context may be maintained as a whole 

30 independent of the raster or drawing operation or series of 
such operations, and may be changed in individual aspects 
retaining the other aspects from previous allocations . 

Figure 5G illustrates the LOAD_PLANE_MASK command format . 
The L 0 AEMP LANE_MA S K command is used to indicate the writeable 
35 planes for all subsequent operations until the next 
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LO AD__P LANE_MAS K operation. The header of the LO AD__P LANE_MAS K 
command provides in the most significant bits an indication 
of the operation code for the LOAD_PLANE_MASK command. The 
length field of the header indicates that one longword follows 
5 the header. The desired PLANE_MASK is held in that longword. 
The PLANE MASK is a bit mask representing which destination 
planes are to be modified. When used with a one-plane 
destination, the bits in the PLANE_MASK field correspond to 
adjacent pixels. Therefore, the PLANE_MASK is set to all ones 
10 for use with a one-plane destination. 

Figure 5H illustrates the format for the LOAD_LU_FUNC 
command. This command sets the logical unit function for 
subsequent operations. The logical unit function controls 
which boolean operation will be performed between the SOURCE 
15 and DESTINATION data. 

The SOURCE data presented to the Pixel SLU 172 depends 
on (i) the data fetched into the GDB 204 (Figure 2) and (ii) 
the interpretation of that data. The data fetched into the 
GDB 204 is controlled by the OP_SETUP command ACTION field 27 

20 (described later .in Figure 5N.) . For ACTION field 27 values 
of MULTI_xxx or EXTRACT_xxx, 8 -bits per destination pixel are 
fetched. For ACTION field 27 values of EXPAND_xxx or 
MONO xxx, 1-bit per destination pixel is fetched. Data 
interpretation is then controlled by the USE__GDB and 

25 PIXEL__EXPAND flags, as well as the OP_SETUP command ACTION 
field 27 value, as follows. 

For USE GDB==0, data held in GDB 204 is ignored. Either 
the foreground or background color register 65 , 73 is used 
depending on the most recent value of the USE_BG flag. For 
30 USE GDB==1, data held in GDB 204 is used whether or not data 
is being fetched into the GDB 204. For PIXEL_EXPAND— 0 f data 
held in GDB 204 is passed straight through to the Pixel SLU 
172. For PIXEL_EXPAND==1, data from GDB 204 is interpreted 
as 1-bit per pixel. If the bit is one, the contents of the 
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foreground color register 65 are presented to the SLU 172 . 

Accordingly, in a preferred embodiment the SOURCE data 
presented to the PIXEL SLU 172 is originated in one of three 
ways : 

5 1. FILL operations. 

In this case, the source data is always the value 
of the foreground register 65 . 

2 . EXPAND operations . 

In these operations, a single plane of source data 
10 is expanded before being presented to the SLU 172. Each 1-bit 
of source data is replaced with the foreground register value 
and each 0-bit of source data is replaced with the background 
register value. 

It is also possible to accomplish color substitution 
when both the source and destination operands are 1 plane. 
This is done by. selecting the OP_SETUP command PIXEL_EXPAND 
flag in conjunction with the appropriate OP_jSETUP command 
ACTION field value. When used in this way, the foreground and 
background registers 65, 73 values represent 8 adjacent pixels 
each. The monochrome pixel value should be replicated 8 
times . 

Use of the PIXEL_EXPAND flag in the OP_SETUP command 
to monochrome (1-bit) destinations is one feature that makes 
the depth of the destination transparent to the lowest level 
25 rendering routines . 

A stipple operation is another form of an expand 
operation. The SOURCE operand is used for the STIPPLE data. 



15 



20 



3. MULTI-PLANE SOURCE 
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If the OP_SETUP command ACTION flag is MULTI__xxxx, 
then the source data is passed through directly to the SLU 
172. 



Figure 51 illustrates the command format for the 
5 LOAD CLIP command. The L0AD_CLIP command loads the working 
registers 67 (Figure 3B) which define the current clip 
rectangle. The clip list command buffer 145 consists of a 
sequence of LOAD__CLIP commands. The header 75 of the 
LOAD CLIP command is formed of an operation code field, a 

10 flags field 83, and a length field. The operation code field 
indicates the LOAD__CLIP command. The flags in the flag field 
include an "end clip unit" (end CU) flag and an "end clip 
list" (end CL) flag. The former flag transfers the command 
stream back to the FIFO command buffer 141, and marks the last 

15 command packet in a clip unit. A clip unit is the set of 
commands required to establish a new clip rectangle. 
Typically, a clip unit consists of either a LOAD_CLIP command 
by itself or a DEST_SETUP command followed by a LOAD_CLIP 
command. 

20 The "end clip list" flag indicates the last -clip 

rectangle specified in the clip list command stream (i.e., the 
end of the clip list command stream) . Clip control codes also 
are provided in flags field 83 as detailed later. A 
CLIP WALKER flag in field 83 determines whether the provided 

25 clip control codes are honored or not. The length field 
indicates three longwords follow header 75. 



The third longword of the L0AD_CLIP command is formed of 
an X Max field and an X Min field. The X Max field provides 
the X coordinate of the rightmost pixel which can be drawn in 
30 this clip rectangle. The X Min field provides the X 
coordinate of the leftmost pixel which can be drawn in this 
clip rectangle. Address generator 196 loads these values into 
registers 67 in Figure 3B. 
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The second and fourth longwords of the LOAD_CLIP command 
provide a Y Min Offset field and a Y Max Offset field. The 
Y Min Offset field provides the byte offset, relative to 
DEST_Y_ORIGIN, of the uppermost scanline which can be drawn 
5 in the clip rectangle being processed. The Y Max Offset field 
provides the byte offset, relative to DEST_Y_ORIGIN, of the 
lowermost scanline which can be drawn in the clip rectangle 
being processed. When the LOAD^CLIP command is executed, the 
Y__MIN_CLIP and Y_MAX_CLIP registers are loaded with the 
10 respective sums of D E S T__Y__ORI GIN and the appropriate offset. 



Figure 5 J illustrates the SET_CLIP__LIST command format. 
The SET_CLIP_LIST command loads a pointer to the current clip 
list and/or changes the enabled state of the clip list . In 
the header of the SET_CLIP_LIST command, the SET_CLIP_LIST 

15 command is indicated in the operation code field. The length 
field indicates that one longword follows the header. A clip 
list address is held in that following longword. This address 
is the physical address of a desired clip list in command 
buffer 145 (Figure 2) . This address is held in two parts - 

20 an offset in save clip register 320, and a base address of the 
block of memory in which clip list buffer 145 resides as- 
indicated in clip base register 318. 

The SET__CLIP__LIST command flags field 83 is similar to 
that of L0AD_CLIP in Figure 51. 

25 Figure 5K illustrates a destination setup command format . 

The DEST_J3ETUP command describes the location and geometry of 
the DESTINATION operand. The DEST_SETUP command is used once 
each time a new DESTINATION operand is selected. The 
DEST__SETUP command can be inserted in the clip list to cause 

30 automatic redrawing to multiple memories. 

The header 75 of the DEST_SETUP data packet includes four 
fields. The operation code field indicates that this command 
is for a DESTJSETUP command. The flags field 83 includes a 
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VIRTUAL flag which, when set, indicates that the DEST_Y_ORIGIN 
field holds a virtual address. When the VIRTUAL flag is 
clear, the DEST_Y ORIGIN field holds a physical address. 
Flags field 83 also provides clip control codes described 
5 later. The length field is set to indicate that two longwords 
follow the header 75 in the DEST SETUP command. 



The second longword of the DEST_SETUP command is formed 
of a DEST Y_ORIGIN field. This field holds the memory address 
of the scanline corresponding to Y=0 in the destination 

10 coordinate space. The starting scanline address for a raster 
operation is computed by the address generator 196 as the sum 
of the contents of this field and the contents of the 
DE S T_Y__OFF SET field of the given raster operation. LOADJ3LIP 
command offsets are also added to DEST_Y_ORIGIN as mentioned 

15 above. The DEST_Y_ORIGIN field is useful, for example, for 
re-establishing value of DEST__Y_ORIGIN without changing 
Y_step . 

The third longword of the DEST_SETUP command is formed 
of a DEST _Y_step field. This field holds the linear byte 

20 offset between .vertically adjacent pixels in the DESTINATION 
operand. For eight -plane operands, this is a byte offset. 
For one-plane operands, this is a bit offset. The graphics 
control unit 130 adjusts the DEST_SCANLINE_ADDRESS by the 
value held in the DEST_Y_step field after each scanline in a 

25 raster operation to advance to the next scanline. 



Figure 5L illustrates the SOURCE__SETUP command format. 
The SOURCE_SETUP command describes the location and geometry 
of the source operand. This command is also used to establish 
the Y and the relative X-Position of the SOURCE operand of a 
30 raster operation function. To that end, this command controls 
translation between the source and destination coordinate 
spaces . 

The header 75 of the SOURCE_SETUP command provides in the 
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operation code field 87 an indication of the SOURCE_SETUP 
command. The flags field 83 includes AUTOMOD and VIRTUAL 
flags among clip control codes (discussed later) . The AUTOMOD 
flag is used in conjunction with tiles. When this flag is 

* 5 set, address generator 196 interprets the source_X_bias field 

as the bias to use if DEST_X equals zero. The address 

* generator 196 then computes the appropriate bias for the 
actual DEST_X. When the AUTOMOD flag is clear , the address 
generator 196 interprets the contents of the source_X_bias 

10 field as the one to use with the initial DEST_X and no 
computation is necessary. When the VIRTUAL flag is set, the 
contents of the source_scanline_address field is a virtual 
address . When the contents of the source_scanline__address 
field is a physical address, the VIRTUAL flag is clear (0) . 

15 Address generator 196 stores the contents of this address 
field as source_Y_base . The source_X_bias field is the least 
significant 16 bits of the header of the SOURCE_SETUP command. 
The value held in this field is to be added to DEST_X to 
determine the pixel offset from the source_scanline_address . 

20 The correct value for source_X_bias field depends on the 
source bit alignment and the translation between the source 
and destination address- spaces. When the source is a tile, 
the source__X_bias field reflects the tile rotation. The 
length field indicates three longwords follow header 75. 

25 The second longword of the SOURCE_SETUP command provides 

the SOURCE_SCANLINE_ADDRESS field. This field holds the 
address of the first source scanline to be referenced in the 
next raster operation. The address is the source scanline 
corresponding to DEST_Y_OFFSET specified in the next raster 

30 operation command. 

The third longword of the SOURCE_SETUP command format 
provides a tile width field and a SOURCE_Y_SETUP field. The 
tile width field holds the logical width of a tile and is an 
optional field used for tiles only. That is, the value of 
35 this field is only used by the address generator 196 when the 
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action field of an OP_SETUP command is set to XXX_Tile. 

The SOURCE_Y_step field holds the byte offset between the 
vertically adjacent pixels in the source operand. The graphics 
control unit 130 adjusts the SOURCE_SCANLINE_ADDRESS field by 
5 this value after each scanline in a raster operation to 
advance to the next scanline. 

Tiles and stipple widths are padded by one full access 
size. That is, the first access size pixels of the desired 
pattern immediately follow the last pixel of the pattern. The 
SOURCE_Y__step field value is set to the naturally aligned 
access size block at or beyond the padded width. The access 
size is four bytes for one-plane operands (stipples) and 
sixteen bytes for eight -plane operands (tiles) . The value of 
the SOURCE_Y_step field for a tile operand (of depth 8, width 
W+16) is computed by logically ANDing the sum of (W+31) and 
0XFFF0. To compute the value of the SOURCE_Y_step field for 
a stipple operand (depth 1, width W+32) r the sum of -W+63 is 
logically ANDed with 0XFFE0 and the results are shifted right 
three bits. To compute the value of the SOURCE_Y_step field 
for a rectangle operand (depth 8, width W) , the sum -(W+3) is 
logically ANDed with OXFFFC. The SOURCE_Y_step field value 
for a rectangle operand (depth 1, width 2) is computed by 
logically ANDing the sum (W+31) and the word 0XFFE0 and 
shifting the results by three bits to the right. 

25 The fourth longword of the SOURCE^SETUP command is formed 

of a source plane index field. This field holds the number 
of the source plane to use for operations which require a 
single-plane source but the source operand is multi-plane. 
Planes are numbered starting at zero (0) , the least 

30 significant bit of each pixel. This field is only useful when 
the action field of an OP_SETUP command specifies an EXTRACT 
operation. 

Figure 5M illustrates the command format for the 
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STENCIL_SETUP command. The STENCIL_SETUP command describes 
the location and geometry of the STENCIL operand. While the 
DESTINATION operand specifies Y using an origin/offset scheme, 
the STENCILJSETUP command specifies a SCANLINE_ADDRESS . The 
5 SCANLINE__ADDRESS is the address of the scanline in the stencil 
corresponding to the first scanline of the destination to be 
processed in the next drawing operation. The STENCILJSETUP 
command must be used to reset the S CANL INE_ADDRE S S whenever 
a new DEST_Y_of f set is specified in a raster operation packet. 
10 The header 75 of the STENCIL_SETUP packet is formed of an 
operation code field, a flags field 83, a length field, and 
a stencil X-bias field. The operation code field indicates 
that this is a STENCIL_SETUP command packet. The flags field 
83 includes a virtual flag which, when set, indicates that the 
15 stencil_scanline__address is a virtual address. When the flag 
is clear, the stencil_scanline_address is a physical address. 
Address generator 196 stores the contents of this address 
field as stencil_Y_base . The length field as illustrated 
indicates that two longwords follow the header 75. 

The second longword is formed of the stencil- 
_scanline__adaress field which holds the memory address of - the 
stencil scanline corresponding to the first destination 
scanline to be accessed during the next raster operation. The 
horizontal and vertical translation of the stencil coordinate 
space relative to the destination is typically fixed for the 
valid lifetime of a sequence of graphics commands. However, 
a STENCIL_SETUP command must be issued whenever the 
DE S T__Y__OFF SET is specified so that the starting 
STENCIL_SCANLINE_ADDRESS can be established. 

30 The third longword of the STENCIL__SETUP command is formed 

of a stencil_Y_step field. This field holds the byte offset 
between vertically adjacent pixels in the STENCIL operand. 
For eight -plane operands, this is a byte offset. For one- 
plane operands, this is a bit offset. The graphics control 
35 unit 300 adjusts the stencil_scanline_address field value by 
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the byte equivalent of the value in the stencil_Y_step field 
after each scanline in a raster operation to advance to the 
next stencil scanline. 

An operation setup (0P_SETUP) command specifies the 
5 number of operands to use, whether to tile, and which depth 
conversion should be used, if any. Bit flags in the operation 
setup command also control transparency, color 
expansion/replacement and selection between the graphics data 
buffer 3 65, the foreground and background registers 65, 73. 
10 The parameters of the operation setup command apply to all 
subsequent operations until the next OP_SETUP command is 
executed. The particulars of the OP_SETUP command are 
illustrated in Figure 5N. 

In header 75, the operation code field is set to indicate 

15 that the command is an operation setup command. The flags 
field includes three flags, PIXEL_EXPAND, USEJ3DB, and 
TRANSPARENCY. The P IXEL_EXPAND flag applies only to one-plane 
data in the graphics data buffer 204. When this' flag is set, 
bits are expanded to pixels before being passed to the Pixel 

20 SLU 172. Each one bit in the graphics data buffer 204 is 
replaced with foreground register pixel value, and each zero 
bit in the graphics data buffer 204 is replaced with 
background register pixel value. The USE_GDB flag, when set, 
provides graphics data buffer data or color-expanded graphics 

25 data buffer data to be delivered to the Pixel SLU 172. When 
this flag is clear, the foreground register value is delivered 
to the SLU 172. This flag exists so that pre-loaded graphics 
data buffer data can be used in place of foreground pixel 
value and background pixel value during fill operations. The 

30 TRANSPARENCY flag controls whether the SOURCE operand bits are 
included in write mask generation. This flag is only useful 
for one-plane sources. When the flag is set, destination 
pixels which correspond to zero bits in the source are not 
modified. 
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The length field indicates that there are no succeeding 
longwords in the 0P_SETUP command. The least significant 
eight bits of the OP__SETUP command provide an ACTION field 27 . 
This field 27 encodes a value which determines which address 
5 generator flow is selected. The encoding includes the number 
and depth of the operands, whether tiling is performed, and 
whether plane extraction is performed. In the preferred 
embodiment, the allowed values of the ACTION field 27 are as 
listed in Table I of the Appendix. 

10 Other graphics commands of the preferred embodiment are 

illustrated in Figures 50 through 5R. 

Figure 50 illustrates the NOP command format. This 
command is used for padding and carrying a number of important 
flags. The NOP command format comprises the header 75 and is 

15 thus one longword long. The operation code field indicates 
the NOP command, and the length field indicates that no 
longwords follow the header 75. The flags field 33 includes 
flags halt, interrupt and. wait_f orjrsynch. The halt flag 
halts address generator 196 so that no further command packets 

20 are executed until the CPU 1D4 restarts the address generator 
196 via a register write. The interrupt flag sends an 
interrupt to the CPU 104 upon execution of this command 
packet . 

The wait_for_vsynch flag stalls execution of the 
25 following command packet until the video scan out of the 
current frame is completed in display device 116 (i.e., 
vertical synchronization) . This feature allows for drawing 
to be queued after a change in the color table. The LOAD_LUT 
command (discussed later) itself does not take effect until 
30 the following video synchronization signal. This flag makes 
it possible to coordinate drawing with the color change by 
delaying further drawing until the next video synchronization 
signal. This flag can also be used to facilitate smooth 
animation. 
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In addition , clip control codes are provided in 3 bits 
of tlie flags field 83. The values of the clip control codes 
are interpreted differently depending on whether the NOP 
command packet is being executed from the FIFO command buffer 
5 141 or the clip list command buffer 145. The commonly used 
values of the clip control codes for drawing unit control (as 
made clearer later) are as follows. 

The value "begin_drawing__unit " saves a pointer , indicated 
in save head register 322 , to the beginning position of a 

10 drawing unit in FIFO command buffer 141 , and sets the "in 
drawing unit" state to TRUE. The "begin_drawing_unit " value 
also toggles or changes execution streams between the FIFO 
command buffer 141 and the clip list command buffer 145. The 
value "end_drawing_unit" in the clip control codes provide a 

15 conditional expression depending on the "in drawing unit" 
state. In particular , if the "in drawing unit" state is TRUE, 
then the "end_drawing_unit " value of the clip control codes 
restores the save head register 322 and toggles * (changes) 
execution streams between the FIFO command buffer 141 and the 

20 clip list command buffer 145. The reason for toggling between 
execution streams at this point is to cause the next clip 
rectangle to be loaded prior to re-execution of the drawing 
commands. If the "in drawing unit" state is NOT TRUE, then 
the "end_drawing_unit" value of the clip control codes 

25 provides no operation. The " transit ion_drawing_unit" value 
of the clip control codes provides the following. If the "in 
drawing unit" state is TRUE, then the save head register 322 
is restored and the execution stream is toggled (changed) 
between the FIFO command buffer 141 and the clip list command 

30 buffer 145. Otherwise, the save head register 322 is set to 
indicate a particular drawing unit and the "in drawing unit" 
state is set to TRUE, and the execution stream is changed 
(toggled) between the FIFO command buffer 141 and the clip 
list command buffer 145. 



35 



Three commonly used values for the clip control codes in 
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clip unit control are as follows. The "save_clip_list_of f set " 
value of the clip control codes saves a pointer to a current 
clip list. In particular, the clip list save register 320 is 
set to indicate the pointer. The "end_clipping unit " value 
5 of the clip control codes provides a toggle or change in 
execution streams between the FIFO command buffer 141 and the 
clip list command buffer 145. The "end__clip_list " value of 
the clip control codes restores the clip list save register 
320, resets the "in drawing unit" state to FALSE, and toggles 
10 execution streams between the FIFO command buffer 141 and the 
clip list command buffer 145. 

These clip control codes are also provided in the flags 
field 83 of the LOADJ3LIP, SET_CLIP__LIST, SOURCE_SETUP, 
DESTJSETDP, ROP_GLYPH, ROP_RECT, and DRAWJLINE commands. And 
15 the foregoing values are interpreted as described above 
depending on whether the command is being executed from the 
FIFO command buffer 141 or the clip list command buffer 145. 

Figure 5P illustrates the format for ■ the command 
STORE_LONG. This command stores a longword literal at an 

20 arbitrary longword address. In particular, this command is 
used to load the base address register 31 and provide the y 
offset value to address generator 196. The first longword of 
the command is header 75. The most significant 8 bits of 
header 75 provide an OPcode indicating the command STORE LONG. 

25 The length field indicates that two longwords follow the 
header 75. Flags field 83 includes a virtual flag which when 
set indicates that the address in the longword following 
header 75 is a virtual address. When clear, the stored 
address is a physical address. Flags field 83 also includes 

30 an interrupt flag similar to that described in the NOP command 
of Figure 50. 

The longword following header 75 of the STORE LONG 
command format holds a memory address at which to store the 
data provided in the second longword following header 75. 
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That data is generally a one longword data value. 

Figure 5Q illustrates the command format for the SET__FIFO 
command. This command moves the memory area in which the FIFO 
command buffer 141 resides , and sets the size and interrupt 
5 masks discussed in the cofiled Application. This command can 
be used to change from one FIFO memory area to another. 
Header 75 of the SET FIFO command format indicates the command 
in the most 8 significant bits. The FIFO masks are indicated 
in the least significant 16 bits of header 75. The length 
10 field indicates that two longwords follow header 75. 

The longword following header 75 holds the physical 
address of the next executable command. That address is held 
in FIFO head index register 316 (Figure 2) . The third 
longword of the SET_FIFO command format holds the physical 
15 address of the next writable location in the FIFO command 
buffer 141. This address is held in the FIFO tail index 
register 312 of Figure 2. 

Ficrure 5R illustrates the format for command LOAD_LUT. 
This command specifies the. frame buffer memory 151 address- of 

20 the color lookup table data which will be loaded by the DAC 
152 after the next frame is displayed on display device 116. 
Header 75 of the LOAD_LUT command format indicates the command 
in the most significant 8 bits, and indicates the length of 
the command format to be one longword following the header 75. 

25 Flag field 83 includes the wait_f or_vsynch flag discussed in 
the NOP command format of Figure 50. The longword following 
header 75 holds the address in frame buffer memory 151 of the 
lookup table data. 

It is noted that the graphics system 100 of the present 
30 invention employs no multiplier. Thus, Y coordinates are 
expressed in terms of scanline addresses. A variable, 
SCANLINE__ADDRESS, holds the address of the beginning of the 
scanline associated with a given Y. For SOURCE and STENCIL 
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operands , the S CANL I NE_ADDRE S S is the address of the scanline 
to be used at the start of the next draw operation. That is, 
SCANLINE_ADDRESS is the address of the SOURCE or STENCIL 
operand scanline used when modifying the initial scanline of 
5 the destination. 



S CANL INE_ADDRE S S is provided for each drawing operation 
unless the draw operation is relying on the internal state 
from the previous draw operation. In the preferred 

embodiment, for SCANLINE_ADDRESS (Y base addresses) , the 

10 hardware maintains no differential between the destination and 
the other operands. For SOURCE and STENCIL operands, 
SCANLINE__ADDRESS is computed in software and passed directly 
to the hardware. Note that for stencils, the translation 
between the STENCIL operand and destination coordinates space 

15 is fixed for a predetermined length of time. However, the 
present invention executes the STENCIL_SETUP command to 
establish SCANLINE_ADDRE SS whenever an explicit DEST_X will 
be supplied in a drawing command data packet. Also, the 
STENCIL_SETUP command is required whenever DEST_Y__OFFSET is 

20 provided in a drawing command. 

The graphics system of the present invention maintains 
the SCANLINE_ADDRESSes for each of the three operands (SOURCE, 
DESTINATION, and STENCIL) as it draws. At the end of a raster 
operation, these S CANL INE_ADDKE S S e s normally point to the 

25 scanline following the one containing the last drawn pixel . 
As a result, trivial commands, such as ROP_POINT and ROP_R£CT 
(used to draw a span) , can progress through a series of 
scanlines without explicitly specifying new S CANL INE__ADDRE S S e s 
for each of the three operands. Similarly, a series of PIXEL 

30 commands can progress across a scanline without explicitly 
specifying X coordinates. This is due to the X_update flag 
in the command which, when set, provides DEST__X to be 
incremented by one after the draw operation. 



Further, it is noted that the flags in the drawing 
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command data packets include one flag to control Y direction, 
one flag to inhibit S CANL INE_ADDRE S S updates, one flag to 
control X direction, and one flag to inhibit DEST_X updates. 

Further, the drawing commands specify offsets from an 
5 origin (the value held in the DEST__Y_origin field) of the 
DEST_SETUP command for specifying the DESTINATION operand. 
The origin is defined as the address of the scanline at which 
Y = 0 in the destination memory space. Thus, the origin 
serves as a base address. As a result , the base address 

10 approach of the present invention allows for the same drawing 
commands to execute against multiple destination memories so 
long as the destination memories have equal Y^steps (i.e., the 
width of a scanline in operand memory or the number of bits 
to effect changing from an x position in scanline Y to the 

15 same x position in scanline Y + 1) . 

By exploiting the foregoing features, software algorithms 
which output points, pixels or- spans can draw with a minimum 
of command data packet overhead. Such savings in the present 
invention graphics system is heretofore not achieved by 
20 graphics systems of the prior art. 

Example uses of the graphics commands of Figures 5A 
through 5N are as follows . These examples show the complete 
set of commands required to do the operation assuming no 
previous context. In practice, many fewer commands are 
25 required for each such operation. These examples are for 
purpose of illustration and not limitation. Further from 
these examples, it is understood that one of ordinary skill 
in the art would be able to formulate desired uses of these 
graphics commands . 

30 EXAMPLE 1 - Simple Rectangle Fill 

If one desires to fill a rectangle area in a certain 
window displayed on the screen of display device 116 (Figure 
1) r the following sequence of graphics commands is performed, 



WO 93/04457 



61 



PCI7US92/07056 



where each linear longword of a command appears on a separate 
line and fields of that command are separated by colons . 

Example 1 Code 

PIXEL : 0 : no draw: foreground val 

5 LOAD_PLANE_MASK : 1 : - 

PLANEMA.SK 

LOAD_LU_FUNC : 0 : COPY 

DESTJSETUP : 2 : dest_X_bias 
de s t _Y_o r i g i n 
10 : dest_Y_step 

LOAD__CLIP : 3 : - 

Y_min__of f set 
Xjmax : X_min 

Y__max_o f f s e t 

15 OP_SETUP : 0 : mult i_f ill 

ROP_RECT : 2 ; DESTJC 
height : width 
dest_Y_offset 

The first line in the above example is a PIXEL command 
specifying a pixel value for foreground color. The address 
generator 196 loads this pixel value into foreground register 
65 in Figure 3B. The no_draw flag is set in this PIXEL 
command and indicates that the PIXEL command is being used to 
just load the foreground register 65. A desired plane mask 
is provided to address generator 196 by the next two lines in 
the above example. The following command (LOAD_LU_FUNC) loads 
the desired logic function, namely the copy function. The 
next three lines set up the pertinent operands which in this 
case is only the DESTINATION operand. The rectangular area 
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of interest in the destination space is specified by the 
LOAD CLIP command. The contents of the X__max field is set 
equal to the width of the desired clip rectangle. The X_min 
field is set to the pixel position of the left edge of the 
5 clip rectangle. The Y_min_of f set field is set equal to the 
product of the minimum Y of the clip rectangle and dest_Y_step 
defined by the previous command. The Y__max_of f set field is 
set equal to the product of the dest_Y_step from the 
DEST__SETUP command and the height specified in the subsequent 
10 raster operation command. 

In the lines following the LOAD__CLIP command is a command 
to set up the desired operation. In particular , the OP__SETUP 
command specifies the plane depth and type of operation. In 
this example, the action field of the OP_SETUP command is set 
15 to "mult i_f ill" which provides filling 8 bits deep. Since the 
USE_GDB flag is not set here, the multi_fill operation will 
use a pixel value defined by the foreground register 65 which 
was set by the pixel command in the first line. 

The lines following the OP_SETUP command is a ROP__RECT 
20 command which places into effect the actual -operation. This 
command specifies the height, width, and starting pixel 
position (DEST__X) directly from the values transmitted by the 
client (CPU 104) . The Y dimension for this operation is 
specified as an offset (dest__Y_of f set) which has a value equal 
- 25 to the product of the Y_step value from the DEST__SETUP command 
and the destination scanline (Y) specified by the client. 
Address generator 196 takes the dest_Y__of f set value from the 
ROP RECT command and adds that value to the dest_Y__origin 
value specified in the DEST_SETUP command, and stores the 
30 result in the destination base address 31 of Figure 3A. 
Address generator 196 subsequently uses the dest_Y_base value 
in base address register 31 as the starting address to 
generate addresses as described in Figure 3A. 



Address generator 196 stores in min Y register 67 (Figure 
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3B) the sume of Y_min_offset from the LOAD_CLIP command and 
Y_origin from the DEST_SETUP command. Also, address generator 
196 stores in max Y register 67 (Figure 3B) the sum of 
Y_max_offset from the L0ADJ2LIP command and Y_origin from the 
5 DEST_SETUP command. 

It is noted that the raster operation command to fill a 
rectangle for one plane destinations is the same as that for 
multiplane destinations. The difference in execution of 
raster operations for these two types of destinations is 
10 specified in the destination setup command Y_step value and 
in the OP_SETUP command ACTION field 27 value which specifies 
multi or mono functions for multiplane or monoplane 
destinations , respectively . 

EXAMPLE 2 - COPY 

15 If one desires to copy a pattern, for example, Pattern 

89 in Figure 6, from a desired source to the same window 91 
as that involved in Example 1 above, the following commands 
are issued subsequent to the commands of Example 1 . ' It is 
noted that because the destination (desired window 91) among 

20 other attributes of the context set in Example 1 are unchanged 
for the current operations, the PIXEL, LOAD__P LANE__MASK , 
LOAD_LU_FUNC, DEST_SETUP, and LOAD_CLIP commands need not be 
repeated. To that end, the registers defined by those 
commands maintain the same values from the command sequence 

25 of Example 1 through the command sequence of Example 2 . This 
also holds true for different registers defined by different 
context commands independent of the other context commands . 
Further, in the ROP_RECT command, the Y_NO_UPDATE flag was 
clear, such that the scanline address for each involved 

30 operand (DESTINATION in this case) was updated by the Y_step. 
Thus , the 

next drawing command begins on the destination scanline 
succeeding the last scanline in the destination space drawn 
to in Example 1 . 
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Example 2 Code 

OP_SETUP : 0 : multicopy 

SOURCE_SETUP : 2 : src_X_bias 
src_Y_base 
5 - : src_Y_step 

ROP_RECT : 2 : DEST_X 
H : W 

Y_offset 

This sequence of commands begins with the OP_SETUP 
10 command to change from the previous Example 1, "Mult if ill" 
operation to the "multicopy" operation. The next command 
(SOURCE_SETUP) defines the source space of desired pattern 89. 
In particular,, the SOURCE__SETUP command specifies the scanline 
in the source memory 95 on which desired pattern 89 begins , 
15 and the width of source memory 95. These two values are 
. specified by source_Y_base and source Y_step, respectively. 
The source X-bias is then defined as the difference between 
the source X transmitted by the client (CPU 104) arid the 
DEST_X defined in the succeeding F_OP_RECT command. This 
20 illustrates that all bias values describe the relationship 
between the specified operand's X and the destination X 
(DEST_X) . 

A ROP RECT command follows the SOURCE_SETUP command and 
provides the actual raster operation desired as discussed 
25 above in Example 1 . 

Further, so long as the Y_offset of a second or more 
sources is the same, then one can use the specifications made 
by the foregoing SOURCE_SETUP command. To that end, to 
specify additional sources respective SOURCE_SETUP commands 
30 for the additional desired sources employ a shortened variant 
of the command. In particular, such subsequent commands do 
not respecify the Y_step field which is already set as desired 
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from the previous SOURCE_SETUP command. Thereafter, the 
ROP__RECT command is repeated for each of the different sources 
(source rectangles) desired to be involved. Likewise , when 
within the same source and in particular on the same scanline 
5 one desires to execute raster operations at different X 
positions, the SOURCE_SETUP command does not need to be 
respecified. Again, this is due to the values specified by 
the SOURCE_SETUP command being held and maintained in 
respective registers until a succeeding SOURCE^SETUP command 
10 is provided, even across plural raster operations. All that 
is required to be repeated are the raster operation commands 
desired. 



EXAMPLE 3 - STENCIL COPY 



To provide stenciling in the window 91 after Example 1, 
15 the following sequence of commands are used. 



Example 3 Code 



OP_SETUP : 0 :multistencil_copy 

SOURCE_SETUP :2 : src X_bias 
src_Y_base 
20 : src_Y_step 

STENCIL_SETUP : 2 : stencil X_bias 
stencil_Y_base 

: stencil Y__step 



ROP_RECT : 2 : Dest_X 
25 H : W 

Y offset 



The OP_SETUP command indicates that a multistencil copy 
operation is to be executed next. The SOURCE_SETUP command 
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specifies the particulars of source 95 as described above in 
Example 2. The STENCIL_SETUP command specifies particulars 
of the desired stencil 90 in a stencil memory 99 as 
illustrated in Figure 6. In particular, the stencil_Y__base 
5 is the scanline in stencil memory 99 on which stencil 90 
begins. Stencil Y_step is the width of the stencil memory 99. 
The stencil X__bias is the difference between the stencil X 
value provided by the client and DEST_X defined in the 
succeeding ROP_RECT command. It is noted that the SOURCE 
10 operand and STENCIL operand are both incremented through their 
respective Y_step values specified in the SOURCE_SETUP and 
STENCIL^SETUP commands . 

To that end, address in source memory 95, address in 
stencil memory 99, and address in destination memory (e.g., 
15 frame buffer 610) of current position within the respective 
memory spaces during drawing is as follows : 

Source address = source_Y__base + source X_bias + DEST_X 
Stencil address = stencil_Y_base + stencil X_bias + 
DEST_X; and 

20 Destination address = DEST_Y + DE5T_X_bias + DEST_X- 

In the case that the destination has multiple clip 
rectangles of interest, a clip list command buffer 145 is 
used. The clip list command buffer 145 contains groups of 
command packets (called a clip unit) which describe the 

25 individual clip rectangles of interest. A clip unit which 
describes a clip rectangle of interest contained in a new 
destination memory is composed of a DEST_SETUP and LOAD_CLIP 
command pair. A subsequent clip unit which describes a clip 
rectangle of interest contained in the same destination memory 

30 may be composed of a single LOAD_CLIP command. In any event, 
a clip unit is stored in clip list command buffer 145 for each 
specified clip rectangle. 



Previous to specifying the desired raster operation 
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commands for operating on the specified clip units , the 
SET_CLIP_LIST command is utilized. This command specifies the 
memory address where the clip list command buffer 145 resides. 
Where a sequence of raster operations is desired for each of 
5 the clip rectangles , the sequence is preceded and succeeded 
by a no-operation command illustrated in Figure 4 . The 
preceding no-operation command provides a flag indicating the 
beginning of a drawing unit, i.e., the desired sequence of 
raster operations. The succeeding no-operation command 
10 provides a flag indicating the end of the drawing unit. 

This allows memory control unit 130 to control the number 
of graphics primitives to be executed per clip rectangle. The 
number of drawing commands executed per clip rectangle is 
changeable, depending on what is being drawn (for example, 
15 vectors, copies, tiles) or on other factors, such as the 
length or type of graphics commands, the mix of commands, or 
whether they involve virtual memory addresses or not. 

Processing of clip list 520 is then as follows and 
illustrated in Figure 4 . 

20 Data packets /graphics commands from FIFO command buffer 

141 are processed one at a time, in order of storage as 
indicated by FIFO head index register 316 (Figure 2) . When 
the SET_CLIP_LIST command is pointed to by head index register 
316 of FIFO control unit 200, address generator 196 reads the 

25 clip list base address specified in the command data packet. 
That address is stored in clip list base register 318 (Figure 
2) . In response to the succeeding no-operation command having 
a "begin drawing unit" flag set, FIFO control unit 200 sets 
save head register 322 to point to the current position in 

30 FIFO command buffer 141 (indicated by an * in Figure 4) . 
Moreover, save head register 322 points to the first 
significant longword in drawing unit 11. In turn, FIFO 
control unit 200 sets the "in drawing unit" state to TRUE and 
toggles to clip list base address in register 318 augmented 
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by (logically ORed with) save clip register 320, to begin 
reading data packets (graphics commands) from clip list 
command buffer 145. The graphics command in clip list command 
buffer 145 to be currently executed is pointed to by clip 
5 index register 319 and is a DEST_SETUP command which specifies 
the destination space to which the current drawing unit 11 is 
to be applied. FIFO control unit 200 continues to read 
graphics commands from clip list command buffer 145 while clip 
list save register 320 is set to the beginning of the current 

10 clip list. Following the initial DEST_SETUP command, a 
LOAD CLIP command is processed. The LOAD_CLIP command 
indicates a desired clip rectangle illustrated in Figure 4 as 
the frame buffer RAM 151 for supporting display unit 116. An 
"end CU" (end clip unit) flag is set in the LOAD_CLIP command. 

15 In response, FIFO control unit 20 0 returns to FIFO command 
buffer 141 at the position indicated by the head index 
register 316. As a result, FIFO control unit 200 processes, 
for the most recently read clip unit, the sequence of raster 
operations f ollowing the no-operation command at the beginning 

20 of the sequence and stops processing upon reaching the no- 
operation command with an end DU flag set. Throughout this 
processing FIFO head index 316 is incremented from ROP x , to 
ROP a in Figure 4. 

In response to the end DU flag, while "in drawing unit" 
25 is TRUE, FIFO control unit 20 0 restores FIFO head index 316 
to the save head 322 position and returns to clip list command 
buffer 145 to the graphics command following the last 
processed graphics command in the clip list command stream. 
As illustrated in Figure 4, the graphics command to which FIFO 
30 control unit 200 returns in clip list command buffer 145 is 
a LOAD CLIP command specifying clip rectangle 15. That 
LOAD CLIP command has an end CU flag set which, in turn, 
causes FIFO control unit 200 to return 'to the position in FIFO 
command buffer 141 to which the FIFO head index register 316 
35 currently points. In this case, the pointer remains pointing 
to the sequence of raster operations in drawing unit 11. FIFO 
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control unit 200 processes these raster operations for clip 
rectangle 15. Upon reaching the no-operation command with the 
end DU flag set succeeding the last raster operation of 
drawing unit 1 1 , FIFO control unit 200 returns to the clip 

y 5 list command buffer 145 (as before) to process the next 

unprocessed clip list graphics command indicated by clip index 

* register 319. 



The foregoing processing of drawing unit 11 for a most 
recently specified clip rectangle (from the last processed 

10 LOAD_CLIP command in clip list command stream) continues until 
a LOAD_CLIP command with an "end CL" (end clip list) flag set 
is processed. That LOAD_CLIP command is necessarily the last 
command in clip list command buffer 145. As such, FIFO 
control unit 200 restores save clip register 320 and resets 

15 the "in drawing unit" state to FALSE. FIFO control unit 200 
then returns to FIFO command buffer 141 to the position 
indicated by FIFO head index register 316. FIFO control unit 
200 processes the raster operations of drawing unit 11. Upon 
reaching the no-operation command following the last raster 

20 operation of drawing unit 11, FIFO control unit 200 tests the 
state of "in draw unit" which was set to FALSE in response to 
the "end clip list" flag of the last processed LOAD_CLIP 
command. In turn, FIFO control unit 200 proceeds to the next 
command 17 in FIFO command buffer 141 (i.e., resets save head 

25 register 322 and set head index register 316 to point to 
command 17) , and continues processing as described previously. 

According to the foregoing, the present invention clip 
list processing method has the advantage that the clip list 
itself and the comparison instructions are written to a memory 

30 only once. Thereafter, the clip list and the comparison 
instructions are processed as memory is read. In the prior 
art, the clip list and the comparison instructions are 
explicitly written into the command stream every time a figure 
is drawn. In addition, the present invention clip list 

35 processing method has the advantage of processing fewer 
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In sum, the address generator 19 6 of the present 
invention accepts data packets (graphics commands) from the 
FIFO command buffer 141 and executes them by requesting memory 
5 reads and writes and by controlling the other megacalls in the 
graphics control unit 130. The graphics operations supported 
are rectangular raster operations and line drawing, although 
the former supports numerous variations. The address 
generator 196 controls the rest of the graphics control unit 

10 130 using one control bus per component and a general bus 
which can broadcast to all components . In particular, the 
present invention address generator 196 generates STENCIL A 
SOURCE and DESTINATION addresses for graphics operation 
accesses as well as control signals for the rest of the 

15 graphics data path. 

Further, address generator 196 uses a minimum number of 
gates and issues graphics requests as quickly as possible. 
A balance is struck between these two achievements by 
parallelling several classes of operations including Y-base 
20 operations, X-coordinate operations, clipping operations r 
width calculations, and shift-count generation. 

EQUIVALENTS 

While the invention has been particularly shown and 
described with reference to a preferred embodiment thereof, 
25 it will be understood by those skilled in the art that various 
changes in form and details may be made therein without 
departing from the spirit and scope of the invention as 
defined by the appended claims . 
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TABLE I 



OP SETUP. ACTION values 



Value 



Meaning 



10 



MULT I FILL 



MONO FILL 



15 



20 



If flag USE_J3DB is clear, fills a full-depth 
destination with the foreground register 
value. If flag USE_GDB is set, fills a full- 
depth destination with the contents of the 
graphics data buffer. 

If flag USE__GDB is clear, fills a 1-plane 
destination with the foreground register 
value. If flag USE_GDB is set, fills a 1- 
plane destination with the contents of the 
graphics data buffer. 

Note that when the destination is 1-plane, 
foreground and background registers must be 
filled with the desired bit value replicated 
8 times . 



25 



MULT I COPY 



MULT I TILE 



EXTRACT COPY 



30 



EXPAND COPY 



35 



Copies a full -depth (8-plane) source to full- 
depth destination. 

Replicates (horizontally) a full-depth tile 
pattern into a full-depth destination. 

Extracts one plane from a full-depth source 
and copies it to a 1-plane destination. 
Monochrome color replacement can be 
accomplished by asserting flag PIXEL_EXPAND 
and loading foreground and background 
registers as for a monochrome system. 

Expands a 1-plane source into a full-depth 
destination using foreground register value 
for each 1-bit in the source and background 
register value for each 0-bit in the source. 
If flag TRANSPARENCY is asserted, only pixels 
corresponding to 1-bit in the source are 
modified. 



EXPAND TILE 



40 



Expands a 1-plane stipple pattern using 
foreground and background register values and 
replicates it into a full-depth destination. 
If flag TRANSPARENCY is asserted, only pixels 
corresponding to 1-bits in the source are 
modified. 
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OP SETUP. ACTION values 



Value 



Meaning 



MONO COPY 



10 



MONO TILE 



15 



MULTI_ 

STENCIL 

COPY 



20 



25 



MULTI_ 

STENCIL_ 

TILE 



30 



35 



EXPAND_ 
STENCIL 
COPY 



Copies a 1 -plane source to a 1-plane 
destination. Color substitution can be 

accomplished by asserting flag PIXEL__EXPAND 
and foreground and background registers 
with the replicated bit -values corresponding 
to foreground and background color. 

Replicates (horizontally) a 1-plane stipple 
pattern to a 1-plane destination. If flag 
TRANSPARENCY is asserted, only pixels 
corresponding to 1-bit in the source stipple 
pattern are modified. 

Copies a full-depth source to a full-depth 
destination "through" a stencil bitmap. That 
is, destination pixels corresponding to 1-bits 
in the stencil are replaced by the 
corresponding source pixel . Destination 
pixels corresponding to 0-bits in the stencil 
are not modified. 

Replicates (horizontally) a full-depth tile 
pattern to a full-depth destination "through" 
a stencil bitmap. That is, destination pixels 
corresponding to 1-bits in the stencil are 
replaced by the corresponding tile pixel. 
Destination pixels corresponding to 0-bits in 
the stencil are not modified. 

Expands a 1-plane source, using foreground and 
background register values to a full-depth 
destination "through a stencil bitmap. That 
is, destination pixels corresponding to 1-bits 
in the stencil are replaced by the 
corresponding color-expanded bit in the 
source. Destination pixels corresponding to 
0-bits in the stencil are not modified. 



40 



If flag TRANSPARENCY is set, then the effect 
is as if the stencil were the intersection of 
the source and the stencil. That is, both the 
source and stencil bits must be set for the 
corresponding destination pixel to be 
modified. Transparency is orthogonal to color 
expansion . 
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Value 



Meaning 



EXPAND^ 
STENCIL 
TILE 



Expands a 1 -plane stipple pattern using 
foreground and background register values and 
replicates it (horizontally) into a full-depth 
destination "through" a stencil bitmap. 



10 



15 



MONO_STENCIL 
COPY 



20 



25 



If flag TRANSPARENCY is set, then the effect 
is as if the stencil were the intersection of 
the source and the stencil. That is, both the 
source and stencil bits must be set for 

the corresponding destination pixel to be 
modified. Transparency is orthogonal to color 
expansion. 

Copies a 1-plane source to a 1 -plane 
destination "through" a stencil bitmap. 

If flag TRANSPARENCY is clear, and flag 
PIXEL_EXPAND is clear then the following 
occurs: Destination pixels corresponding to 
1-bits in the stencil are replaced with the 
corresponding bit in the source. 

If flag TRANSPARENCY is clear, and flag 
PIXEL_EXPAND is set then the following occurs: 
Destination pixels corresponding to 1-bits in 
the stencil are replaced with foreground 
register value if the source bit is 1 and 
background register value if the source bit is 
0. 



30 



35 



If flag TRANSPARENCY is set, then the effect 
is as if the stencil were the intersection of 
the source and the stencil. That is, both the 
source and stencil bits must be set for 

the corresponding destination pixel to be 
modified. Transparency is orthogonal to color 
substitution . 



MONO_STENCIL_ Replicates (horizontally) a 1-plane stipple 
TILE pattern to a 1-plane destination "through" a 

stencil bitmap. 
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We claim: 

11. In a computer graphics system having means for 

2 operating on data from a desired source area in source memory 

3 and storing resulting data in a desired destination area in 

4 destination memory, the destination memory having an initial 

5 memory position from which positions in the destination memory 

6 are addressed, the destination area having an origin within 

7 the destination memory, a method of addressing comprising the 

8 steps of : 

9 for a given position in the destination area 

10 relative to origin of the destination area, determining a 

11 working distance from the origin to the given position along 

12 one axis; and 

13 forming a destination memory address of the given 

14 position relative to initial memory position of the 
.15 destination memory as a function of the determined working 

16 distance. 

12. A method as claimed in Claim 1 wherein the step of 

2 forming a destination memory address further includes: 

3 providing a differential distance between the origin 

4 of the destination area and initial memory position of the 

5 destination memory along the one axis; and 

6 summing the determined working distance and the 

7 differential distance. 

13. a method as claimed in Claim 1 further comprising 

2 the step of forming source memory addresses of data in the 

3 source area as a function of the determined working distance. 
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14. A method as claimed in Claim 1 further comprising 

2 the steps of : 



3 providing a stencil memory source of data, the 

4 stencil memory having a stencil area holding data of interest; 

5 and 

6 forming stencil memory addresses of positions of 

7 data in the stencil area as a function of the determined 

8 working distance. 

15. A method as claimed in Claim 1 further comprising 

2 the steps of : 

3 as a function of width of the destination memory 

4 along the one axis, specifying an offset distance from the 

5 origin of the destination area to the given position along a 

6 Y-axis perpendicular to the one axis, said offset distance 

7 enabling formation of a Y-axis component of the destination 

8 memory address of the given position, such that for a 

9 plurality of additional destination memories having the same 

10 width as the destination memory, of the desired destination 

11 area, a Y-axis component of each destination memory address 

12 is formed by a common computation, effectively eliminating 

13 recomputation of the Y-axis component of the respective 

14 destination memory address for each of the plurality of 

15 additional destination memories. 



1 6. A method as claimed in Claim 1 furher comprising the 

2 steps of : 

3 providing distance from initial memory position of 

4 the destination memory to the origin of the destination area 

5 along a Y-axis perpendicular to the one axis, said distance 

6 being a Y-origin distance; 



7 



specifying an offset distance from the origin of the 
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8 destination area to the given position along the Y-axis as a 

9 function of width of the destination memory along the one 

10 axis; and 

11 forming a Y-axis component of the destination memory 

12 address of the given position, by summing the Y-origin 

13 distance and the offset distance. 

17. A method as claimed in Claim 6 further comprising 

2 the step of automatically updating position along the Y-axis 

3 in each of desired source and destination areas such that for 

4 vertically adjacent operations, addresses of positions in each 

5 of desired source and destination memories are able to be 

6 formed from specification of desired position in the 

7 destination area along the one axis and width of the 

8 destination memory along the one axis . 



1 8. In a computer graphics -system, having (i) graphics 

2 commands for providing desired graphics operations on 

3 specified data, (ii) a communication bus, and (iii) data 

4 packets of fixed length in which graphics commands are 

5 transmitted on the communication bus, the improvement 

6 comprising: 

7 a graphics command format, for each graphics command 

8 the graphics command format having a multiplicity of fields, 

9 different fields for specifying different parameters of the 

10 graphics command, the fields being arranged in order of common 

11 use such that less commonly used fields are at an omittable 

12 end of the graphics command format enabling length of the 

13 graphics command to vary as a function of parameters specified 

14 in the graphics command. 

1 9 . A graphics command as claimed in Claim 8 wherein the 

2 . graphics command format includes a length field for indicating 

3 present length of the graphics command. 
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1 10. A graphics command as claimed in Claim 8 wherein the 

2 graphics command format includes a flag for inhibiting 

3 automatic updating* of a scanline in working memory. 



1 11. A graphics command as claimed in Claim 8 wherein the 

2 graphics command format includes a flag for inhibiting 

3 automatic updating of pixel position on a given scanline in 

4 working memory. 

1 12 . A graphics command as claimed in Claim 8 wherein the 

2 graphics command format includes a flag for indicating 

3 direction of processing along an axis in a working memory. 

1 13. A graphics command as claimed in Claim 8 wherein the 

2 graphics command format includes a flags field for controlling 

3 clip list processing. 

1 14. In a computer graphics system having graphics commands 

-2 for providing desired graphics operations on specified data, 

3 a method of processing graphics commands comprising the steps 

4 of: 



5 providing a graphics command format for each 

6 graphics command, the graphics command format having a 

7 multiplicity of fields arranged in order of common use such 

8 that fields required for each use of a command are at a 

9 beginning of the graphics command format and less commonly 

10 used fields are at an end of the graphics command format; 

11 specifying for a first time a desired graphics 

12 command including providing a respective value in each of the 

13 multiplicity of fields of the graphics command format for the 

14 desired graphics command; 



15 
16 



processing the specified desired graphics command 
including storing in respective registers the values provided 
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17 in the fields of the graphics command format; 

18 specifying for a second time the desired graphics 

19 command by providing respective values in required fields and 

20 certain selected fields and by leaving certain ones of the 

21 less commonly used fields unspecified such that length of the 

22 desired graphics command is shortened with respect to the 

23 first time of specifying the desired graphics command; and 

24 transmitting the shortened desired graphics command 

25 as specified the second time for processing thereafter. 

1 15 . A method as claimed in Claim 14 further comprising the 

2 step of processing the desired graphics command as specified 

3 the second time by (i) changing values stored in registers 

4 corresponding to the required fields and certain selected 

5 fields of the graphics command format to store the respective 

6 values provided in the second time specification of the 

7 desired graphics command, and (ii) maintaining values from the 

8 first time specification of the desired graphics command 

9 stored in registers corresponding to the fields left 

10 unspecified in the second time specification of the desired 

11 graphics command such that the desired graphics command is 

12 processed with values for each of the multiplicity of fields 

13 of the graphics command f ormat . 

1 16. In a computer graphics system having a command buffer 

2 holding a series of graphics commands for performing desired . 

3 graphics operations on specified data, a method of processing 

4 graphics commands comprising the steps of: 

5 for a desired series of drawing graphics commands, 

6 forming a memory list indicating multiple desired destination 

7 areas, each for storing data resulting from execution of the 

8 desired series of drawing graphics commands, the memory list 

9 having a different entry for each desired destination area and 
10 each entry providing a memory address of corresponding 
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11 destination area; 

12 providing in the command buffer a list-setting 

13 graphics command indicating a memory address of the memory 

14 list for accessing the memory addresses of the desired 

15 destination areas; 

16 storing the desired series of drawing graphics 

17 commands in the command buffer after the list-setting graphics 

18 command, said storing including providing a beginning 

19 indicator for indicating beginning of the desired series of 

20 drawing graphics commands and an ending indicator for 

21 indicating end of the desired series of drawing graphics 

22 c ommands ; and 



23 sequentially executing the graphics commands held 

24 in the command buffer such that the list-setting graphics 

25 command is executed before the desired series of drawing 

26 graphics commands, and said sequential executing includes: 

27 (i) in response to the list-setting graphics 

28 command, accessing the memory list with the memory address 

29 indicated in the list-setting command, 

30 (ii) sequentially reading the entries of the 

31 memory list and for each entry executing the desired series 

32 of drawing graphics commands as delimited by the beginning and 

33 ending indicators in the command buffer, such that the desired 

34 series of drawing graphics commands is executed once for each 

35 desired destination area but stored as a single occurrence in 

36 the command buffer. 

1 17. The method of Claim 16 wherein the step of sequentially 

2 reading the entries of the memory list further includes, for 

3 a current entry, after executing the desired series of drawing 

4 graphics commands, reading a succeeding entry in the memory 
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5 list in response to the ending indicator in the command 

6 buffer. 

1 18. A method as claimed in Claim 16 wherein the step of 

2 forming the memory list further includes providing an 

3 indicator for indicating last entry of the memory list; and 



4 the step of sequentially reading the entries of the 

5 memory list further include, in response to reading the last 

6 entry of the memory list, executing the desired series of 

7 drawing graphics commands a last time. 

1 19. In a computer graphics system, apparatus for processing 

2 graphics commands comprising: 

3 a command buffer holding at least a series of 

4 drawing graphics commands for performing desired graphics 
-5 operations on specified data; 

6. a memory list indicating multiple desired 

7 destination areas for the series of drawing graphics commands 

8 held in the command buffer, each desired destination area for 

9 storing data resulting from execution of the series of drawing 

10 graphics commands, the memory list having a different entry 

11 for each desired destination area and each entry providing a 

12 memory address of corresponding destination area; 

13 processing means for sequentially reading the 

14 entries of the memory list and for each entry executing the 

15 series of drawing graphics commands in the command buffer, 

16 such that the series of drawing graphics commands is executed 

17 once for each desired destination area but stored as a single 

18 occurrence in the command buffer. 
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1 20, Apparatus as claimed in Claim 19 further comprising: 

2 a list-setting indicator associated with the series 

3 of drawing graphics commands stored in the command buffer for 

4 indicating memory address of the memory list; 

5 a beginning indicator for indicating beginning of 

6 the series of drawing graphics commands stored in the command 

7 buffer; 

8 an ending indicator for indicating end of the series 

9 of drawing graphics commands stored in the command buffer; and 

10 an entry indicator for indicating current entry in 

11 the memory list for which the series of drawing graphics 

12 commands is being executed, such that the processing means 

13 accesses the memory list through the list-setting indicator 

14 before executing the series of drawing graphics commands a 

15 first time and thereafter executes the series of drawing- 

16 graphics commands from the beginning as indicated by the 
17« beginning indicator to the end as incicated by the ' ending 

18 indicator, for each entry in .the memory list as indicated by 

19 the entry indicator, the entry indicator being updated after 

20 each execution of the series of drawing graphics commands. 

1 21. In a computer graphics system, a method of performing 

2 desired graphics operations on specified data, comprising the 

3 steps of : 

4 providing a plurality of drawing graphics commands, 

5 each for specifying a different raster drawing operation 

6 independent of context; 

7 defining a context in which drawing graphics 

8 commands operate to provide desired graphic operations on 

9 specified data, the context including destination location for 
10 resulting data, type of graphics operation, foreground color 
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11 of resulting data, and background color of resulting data, 

12 said defining including using a plurality of context graphic 

13 commands, different context graphics commands for defining 

14 different parts of the context independent of other parts of 

15 the context; and 

16 selecting and executing in the defined context T one 

17 of the drawing graphics commands such that the raster drawing 

18 operation corresponding to the selected drawing graphics 

19 command is performed on specified data with respect to the 

20 defined context to provide desired graphics operations on the 

21 specified data. 

1 22. A method as claimed in Claim 21 further comprising the 

2 step of redefining the context by using a single context 

3 graphics command to redefine one part of the context, the 

4 other parts of the context remaining as previously defined. 

1 23. A method as claimed in Claim 21 wherein context graphics 

2 commands include commands for defining clip list processing 

3 and commands for defining type of graphics operations 

4 separately from clip list processing. 
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ABSTRACT: 

CHG DATE=19990617 STATUS=0>In a computer 
graphics system, an address generator processes 
physical and virtual addresses using a common 
command set. A separate translator provides 
conversion from generated virtual addresses to 
physical addresses . The address generator 
formulates addresses as a function of distance 
from the origin of desired destination area in 
destination memory to the requested position in 
the destination area. A plurality of drawing 
graphics commands specify different raster drawing 
operations. A plurality of context graphics 
commands is used to define a desired context in 
which drawing graphics commands operate. The 
defined context includes destination location for 
resulting data, type and plane depth of graphics 
operations, foreground and/or background color of 
resulting data. Different parts of the context are 
changeable/redef inable independently of the other 
parts. The graphics commands have a format of 
multiple fields. Different fields specify 
different parameters. For each graphics command, 
the fields are arranged in order of common use of 
the corresponding parameter such that fields of 
less commonly used parameters are at an omittable 
end of the format. Thus, length of each graphics 
command varies as a function of parameters 
specified in the graphics command. A desired set 
of raster drawing commands delimited by a 
beginning indicator and an end indicator form a 
drawing unit. For clip list processing, a drawing 
unit is stored as a single occurrence in the 
system command buffer but functionally serves as a 
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processing loop. Processing alternates between the 
drawing unit held in the command buffer and a clip 
list that specifies desired clip rectangles, the 
drawing unit being repeated for each clip 
rectangle . 
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